2009/9/23 Thomas Sundberg <thomas.sundb...@agical.com>: > On Wed, Sep 23, 2009 at 11:22, Manuel Grau <mang...@gmail.com> wrote: >> >> I suggest to you that you use maven-j2ee-archetype. I'm using it and it's >> great. If you need more help, let me know. >> > > I asked my friend Google and found an archetype called > 'maven-archetype-j2ee-simple' > > http://maven.apache.org/plugins/maven-archetype-plugin/examples/j2ee-simple.html > > The directory layout could be sufficient, but it doesn't state > anything about integration testing or where it will fit in the module > structure. > > So my question remains. How would you suggest that the integration > testing is fitted into the modules?
This depends on how and when you want to fail the build and what you class as integration testing. An example. I have a war module. Best practice is to keep the java classes in a separate module. That java module depends on other java modules. I have unit tests in each java module. IMHO, unit tests should not depend on anything else. They use, e.g. mock database connections, and they mock out the other java modules. I have class 1 integration tests in each java module. These integration tests are where I do not mock out the other java modules, but I do not depend on external stuff... so I might still have a mock database connection. Both of the above are run using maven-surefire-plugin as part of the "test" phase of the build, and they are all JUnit based tests I have class 2 integration tests in each java module. These integration tests are where I depend on external stuff that can be provided locally... e.g. I start up a local database in the pre-integration-test phase and I tear the database down again in the post-integration-test phase. The tests are JUnit based tests which I run using the failsafe-maven-plugin. These tests are in a profile called "run-its" and the profile is not enabled by default, but is enabled on the CI server. I have class 2 integration tests in the war module. These integration tests use jetty to set up a war container and stop it again using pre- and post- integration test phases again.. I also start and stop a local database instance with test data. I run browser based tests. Currently these integration tests are more of a smoke test and they just use HttpUnit or HtmlUnit (I forget which) over JUnit and I am again using the failsafe-maven-plugin to run these tests... again they are in a profile called "run-its" I have class 3 integration tests in a separate module. I consider class 3 integration tests to be integration tests that require an external environment that cannot be provided locally. This module is only added to the aggregator pom when the profile "run-its" is enabled. This module uses cargo to deploy the war to a remote application server, and uses dbunit to restore a remote database to a known state. we then run selenium based tests of the remote system. The remote system is controlled by a property, and we have a virtual machine template for this environment which developers can clone as they need... I am working on the virtualization-maven-plugin to allow for automatic cloning of vm templates, and setting a property based on the ip of the clone, and destroying the clone afterwards. The net result of all this is: 1. developer builds will fail if any unit test fails. unit tests are fast and can always run. IDE debugging support is easy 2. developers can run the class 1 and class 2 integration tests any time they like, but debugging them from the IDE requires starting a command line (or using native m2 integration) to run the "verify" phase of the module they want to test with -Dmaven.surefire.debug=true or -Dmaven.failsafe,debug=true (depending on which plugin is running the tests, and then attaching a remote debugging session to the tests. 3. developers can run the class 3 integration tests any time, but they have to provision themselves a test environment. When I get the virtualization-maven-plugin supporting clone deployment, this will be a lot easier. debugging is as for class 1 and class 2. 4. The CI server has its own dedicated test environment (we use hudson with the locks-and-latches plugin to ensure that multiple jobs do not clobber the test environment) and has jobs which run using the -Prun-its profile to ensure that integration tests are tracked and failures are identified early. -Stephen > > /Thomas > > As a sidenote, I totally agree with the quote from Dijkstra. > > >> >> 2009/9/23 Thomas Sundberg <thomas.sundb...@agical.com> >> >> > Hi! >> > >> > I'm about to set up en fresh project using Maven. It will contain a web >> > part >> > that will be a war, it will contain a ear part and it will contain >> > integration tests. How would you suggest organising it? >> > >> > I'm thinking on the lines of: >> > >> > root -- >> > -- ear [Mostly packaging for a application server] >> > >> > -- war -- src -- main -- java ... >> > -- test -- java ... [Unit test, not depending on any >> > external resources] >> > >> > -- integration-test -- src -- main -- java ... [Probably more or less >> > empty] >> > -- test -- java ... [All integration >> > tests needed, including >> > Selenium, >> > Database and similar stuff >> > that will >> > require a deployed and running application] >> > >> > It is likely that I will add more modules as the system expands. Each >> > module >> > will be self dependant regarding the unit testing and the Integration tests >> > will depend on these other modules. >> > >> > Do you have any suggestions that I want to consider with this set-up? >> > There might be more then one practise and probably more then one good >> > practise. There might not exist any best practise so I want to consider >> > more >> > then one set-up before I make up my mind. >> > >> > Best regards >> > Thomas >> > >> > -- >> > Thomas Sundberg >> > M. Sc. in Computer Science >> > >> > Agical AB >> > Västerlånggatan 79, 2 tr >> > 111 29 Stockholm, SWEDEN >> > >> > Mobile: +46 70 767 33 15 >> > E-mail: thomas.sundb...@agical.com >> > http://www.agical.com >> > Blog: http://thomassundberg.wordpress.com/ >> > >> >> >> >> -- >> "Computer science is not about computers any more than astronomy is about >> telescopes." E.W. Dijkstra (1930-2002) > > > > -- > Thomas Sundberg > M. Sc. in Computer Science > > Agical AB > Västerlånggatan 79, 2 tr > 111 29 Stockholm, SWEDEN > > Mobile: +46 70 767 33 15 > E-mail: thomas.sundb...@agical.com > http://www.agical.com > Blog: http://thomassundberg.wordpress.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
