Need Browser Based Testing

[spekary]

There is so much interaction between the javascript and the form objects, we really need unit tests for this. This is not trivial work. I don't think we need to attach it to Travis initially, but eventually.

This will require Selenium or possibly StoryPlayer to drive the browser, probably. There are a few testing frameworks out there for this. The trick is going to be to drive the browser, and then examine the PHP state of the code.

[spekary]

Actually, I think we can do something like this from within QCubed. I recently introduced a new action parameter that lets you specify an event priority that waits until the event queue is completely empty before executing the associated action. This will be particularly helpful, as you can then post events that essentially wait for all other events to finish. That event can then launch the next event in the testing process.

We need to modify qcubed.js so that an event can be sent into the event queue of another window, either a child window or a parent window. This would let us then have a qcubed application essentially launch and control another qcubed application, and wait for results. Then internal state could be checked as well, in particular by unpacking the formstate. Would take some work, but this would allow us to use the entire examples website as a unit test.

[spekary]

I have marked this as for version 5.0, but its a feature that could be implemented any time.