Best approach to integration test a Flex/Java web application via Maven?

I am working on a project that is developing a webapp with a 100% Flex UI that talks via Blaze to a Java backend running on an application server. The team has already created many unit tests, but have only created integration tests for the persistence module. Now we are wondering the best way to integration test the other parts. Here are the Maven modules we have now, I believe this is a very typical design:

Server Side:

1) a Java domain module -- this only has unit tests

2) a Java persistence module (DAO) -- right now this only has integration tests that talk to a live database to test the DAOs, nothing really to unit test here

3) a Java service module -- right now this only has unit tests

Client Side:

4) a Flex services module that is packaged as a SWC and talks to the Java backend -- currently this has no tests at all

5) a Flex client module tha开发者_运维问答t implements the Flex UI on top of the Flex services module - this has only unit tests currently (we used MATE to create a loosely couple client with no logic in the views).

These 5 modules are packaged up into a WAR that can be deployed in an application server or servlet container.

Here are the 4 questions I have:

1. Should we add integration tests to the service module or is this redundant given that the persist module has integration tests and the service module already has unit tests? It also seems that integration testing the Flex-Services module is a higher priority and would exercise the services module at the same time.
2. We like the idea of keeping the integration tests within their modules, but there is a circularity with the Flex services module and the WAR module. Integration test for the Flex services module cannot run without an app-server and therefore those tests will have to come AFTER the war is built, yes?
3. What is a good technology to integration test the Flex client UIs (e.g. something like Selenium, but for Flex)?
4. Should we put final integration tests in the WAR module or create a separate integration testing module that gets built after the WAR?

Any help/opinions is greatly appreciated!

More an hint than a strong answer but maybe have a look at fluint (formerly dpUInt) and the Continuous Integration with Maven, Flex, Fliunt, and Hudson blog post.

First off, just some clarification. When you say "4) Flex services module packaged as a SWC", you mean a Flex services library that I gather is loaded as an RSL. It's an important differential than writing the services as a runtime module because the latter could (and typically would) instantiate the services controller itself and distribute the service connection to other modules. Your alternative, simply a library you build into each module means they all create their own instance of a service controller. You're better off putting the services logic into a module that the application can load prior to the other modules loading and manages the movement of services between.

Eg.

Application.swf - starts, initialises IoC container, loads Services.swf, injects any dependencies it requires

Services.swf loads, establishes connection to server, manages required service collection

Application.swf adds managed instances from Services.swf into it's container (using some form of contextual awareness so as to prevent conflicts)

Application.swf loads ModuleA.swf, injects any dependencies it requires

ModuleA.swf loads, (has dependencies listed that come from Services.swf injected), uses those dependencies to contact services it requires.

That said, sticking with your current structure, I will answer your questions as accurately as possible.

1. What do you want to test in integration? That your services are there and returning what you expect I gather. As such, if using Remote Objects in BlazeDS, then you could write tests to ensure you can find the endpoint, that the channels can be found, the destination(s) exists, that all remote methods return as expected. The server team are testing the data store (from them to the DB and back), but you are testing that the contract between your client and the server still holds. This contract is for any assumptions - such as Value Objects returned on payloads, remote methods existing, etc, etc.

2. (See #4 below) The tests should be within their module however I would say here that you really should have a module to do the services (instead of a library as I suggested above). Regardless, yes still deploy the testing artifacts to a local web-server (using Jetty or some such) and ensure the integration tests goal depends on the WAR packager you use.

3. I find some developers interchange UI/functional testing with integration testing. Whilst you can indeed perform the two together, there is still room for automated integration tests in Flex where a webserver is loaded up and core services are checked to ensure they exist and are returning what is required. For the UI/functional tests, Adobe maintain a good collection of resources: http://www.adobe.com/products/flex/related/#ftesting. For integration tests as I mentioned,

4. Integration tests should have their own goal that depends the packaged WAR project.