2009/9/23 Stephen Connolly <stephen.alan.conno...@gmail.com>: > 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.
I forgot to add... that because these class 3 tests are in a separate module, they get built last in the build chain (we list them last in the list of modules because they are in a profile and as nothing else depends on them, so they don;t get pulled up the build order) so that developers building the whole project can get the artifacts, e.g. the war built even if the class 3 integration tests are failing. This does mean that if the class 3 integration tests are failing, you only find out at the end of the build, and when a developer is working on one module, they will only know they have broken a downstream module when either: 1. the CI system emails them saying "you broke the build" or 2. when they do a full build. This is because developers have a habit of doing like so svn co http://project/trunk project cd project mvn clean install -DskipTests cd module1 # do work on module 1 mvn verify # do more work on module 1 mvn -Prun-its verify svn ci -m "I've made my changes" if they do not remember to go: cd .. mvn verify -Prun-its before the commit, then they will miss the fact that they have broken the independent module integration tests (i.e. the class 3 tests) I would also argue that class 3 tests should always be in a separate module as you may not always have the required test environment available. Class 3 tests would also include tests that require deploying to, e.g. a WebSphere server. The developer has likely installed that on their local machine, so they set a property in their settings.xml <property> <was60>c:\\foo\\bar\\was6</was60> </property> and we use that property in our class 3 integration test module. > > 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
