Lets talk more about this tomorrow at the team meeting, but I want to be careful to scope the work for the quickstart.  We want to show some good ways to get started with qunit, and validating basic aspects of the JavaScript, and Dom.  I'm not sure moving into integration testing is in that scope - at least for the quickstart. 

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. 

It might make sense to hold off on too many more qunit updates until Kris can take a look next week.  I believe he has some good experience here through jQuery UI.  I also know that Lukas has been doing work around JavaScript testing and integrating in to arquillian - JavaScript testing integration so he might be another one we can talk to about this.  For the quickstart however we might want to keep it simple enough to grasp the concepts quickly.

Thanks for this links.

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,

however JavaScript code needs to be covered with unit tests (QUnit)

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. ;-)

Ah, it would be really nice prototype something like that, but it's currently out of my focus. :-)

However with all other mentioned techs, you could count with me.