Will there be any improvements in Maven 3 and it's support for the plug-ins related to testing/coverage?
Regards, Stevo. On Wed, Sep 23, 2009 at 2:19 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > 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 > >
