I do think that selenium is likely the best way to move from unit testing to integration testing. I'm not sure about the idea of the iframe, but I'll have to review more when we have time.
I think you already stubbed this out as a TODO?
It made sense to have better tests with the jQuery upgrade. It should have actually been handled when the project was created - but I know you were short on time.
Jay Balunas wrote:
It might make sense to hold off on too many more qunit updates until Kris can take a look next week.
I won't worry about testing the code anymore at this point.
Jay Balunas wrote:
I'm not sure about the idea of the iframe, but I'll have to review more when we have time.
In this case, I would not recommend the iframe approach. There is too much going on with that page to run effective tests and you want to simplify your tests down to basic functionalites so you know exactly what is breaking.
Testing the HTML5 validation will be hard if not impossible since not all browsers support it so you'll want to stick to testing the other validation. To do that, I would just set up a simple form that mimics the user form and test with that. The iframe is probably a bad idea because your validation is happening asynchronously so you'll need to use asyncTest in QUnit and probably some other event capturing to get a proper test and doing that within the iframe just gets messy.
I would be happy to take a stab at writing some of our initial tests if you would like.
I think it would be great if you could take a look at updating the qunit tests, and provide any comments, updates, etc... Please create a sub-task for AEROGEAR-120 to cover updating the qunit tests for the quickstart.
For the AS-* quickstart just remember the priority is introducing the technology and getting new users to see the value, base functionality, etc... For the AeroGear specific examples we can get more in depth.
The work to make Arquillian run QUnit tests is currently focused on plain runner for QUnit tests, without any integration with server side
but still integrated to Arquillian ecosystem - thanks to Drone - the Arquillian's Selenium runner - QA does not need to configure browser pool twice for Selenium and QUnit tests.
But what may be interesting for you, we want to allow tests to cover app from client to server and back (doing validation / assertions on both sides).
This concept could use potentionally any client automation tool (Selenium / HtmlUnit / HttpUnit) and assert validations in potentionally any UI technology which have right hooks into own lifecycle (like JSF phase listeners) which could be registered by tested application. Still, we are targetting Java, because assertion objects needs to be enhanced by Arquillian.
Arquillian also enables testing on Android emulators (Alpha1 released), which helps you to avoid usage of real devices in QA Labs.
Selenium itself has nice API for using Touch interface and also accessing HTML5 APIs like WebStorage from within Java API.
So all over, for integration/functional tests I would recommend Selenium,
and thus for testing plain JS interfaces, I would use probably mocking approach (I have not tried yet, but I'm big fan of Java-version of Mockito, so I would try: http://jsmockito.org/).
With some custom work, you could even mock the REST end-point "triggered by AJAX" without any server round-trip (pure client-side) -
it could be nice framework. ;-)