You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Thomas Sundberg <th...@agical.com> on 2009/09/23 10:31:41 UTC
Organise integration tests in a Maven project
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.sundberg@agical.com
http://www.agical.com
Blog: http://thomassundberg.wordpress.com/
Re: Organise integration tests in a Maven project
Posted by Stevo Slavić <ss...@gmail.com>.
I'm not short circuiting anything, and I know that tests should be run first
on clean non instrumented code, then only if tests pass run instrumentation
and get and verify coverage. I was having solely Maven 2 shortcomings on my
mind, like:
- not being able to get aggregated coverage report in parent module for
it's child modules (parent is built before child modules);
- lifecycle being inflexible forcing one to create multiple modules e.g.
functional tests can not be pre-,run,-post,verify first with clean code, and
then only if tests pass do that again with instrumented code so that
coverage is checked with having source and all its tests (regardless of
type) in same module. One can create multiple modules if project is simple
single web site module, but if project is complex with multiple front ends
(war modules), all reusing e.g. some service modules, with separate
functional tests and/or coverage modules one gets explosion of modules which
not even eclipse/m2eclipse can handle well;
- one can not set explicit order of plugins in which they are supposed to
be executed, one can only hope that plugins will be executed in order they
are listed but not even that is guaranteed (e.g. one can not achieve start
server 1, start server 2, run tests, stop server 2, stop server 1; only
start server 1, start server 2, run tests, stop server 1, stop server 2)
Regards,
Stevo.
On Thu, Sep 24, 2009 at 12:12 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> I don't know.
>
> The issues with testing/coverage are largely due to people misunderstanding
> what side-effects measuring code coverage can have, and therefore trying to
> short-circuit the tests and only run the tests once.
>
> I can get into quite a rant on this, but essentially,
>
> I have seen simple code where people do not think threading would even be
> involved, and the tests pass when instrumented and fail when not
> instrumented... from this I concluded that if you have me or somebody worse
> at coding than me on your team, you must always ensure that the tests are
> run without coverage instrumentation.
>
> I have seen simple code where the tests pass without instrumentation and
> fail with instrumentation (and I'm not talking performance tests) 9 times
> out of 10, when I looked into it the failure would be replicated by
> switching to a different JVM... and when I looked at the code I would see
> that both the pass and the fail were valid under the JVM spec... from this
> I
> concluded that if you have me or somebody worse at coding than me on your
> team, you must always ensure that the tests are run with coverage
> instrumentation... and you probably want to also run the tests on a
> different vendor JVM on a different CPU architecture (with or without
> instrumentation)
>
> Instrumentation with emma/cobertura/clover will catch, IMHO, about 80% of
> the bugs due to people failing to understand how the JVM spec can re-order
> operations and optimize code.
>
> So my conclusions are that you always need to run the tests at least twice.
> I agree that the current situation where running
>
> mvn clean deply site-deploy
>
> can result in the unit tests being run 10-15 times over is ridiculous...
> hopefully some of the lifecycle-forking changes that are required to fix
> this will be available in 3.x
>
> I suspect that a lot of the fixes for this could be implemented in the 2.x
> branch too, or even natively in the plugins (e.g. by having the reporting
> plugins not fork the build, and not having @aggregator mojos)
>
> -Stephen
>
> 2009/9/24 Stevo Slavić <ss...@gmail.com>
>
> > 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.connolly@gmail.com> wrote:
> >
> > > 2009/9/23 Stephen Connolly <st...@gmail.com>:
> > > > 2009/9/23 Thomas Sundberg <th...@agical.com>:
> > > >> On Wed, Sep 23, 2009 at 11:22, Manuel Grau <ma...@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 <th...@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.sundberg@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.sundberg@agical.com
> > > >> http://www.agical.com
> > > >> Blog: http://thomassundberg.wordpress.com/
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > >> For additional commands, e-mail: users-help@maven.apache.org
> > > >>
> > > >>
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
>
Re: Organise integration tests in a Maven project
Posted by Stephen Connolly <st...@gmail.com>.
I don't know.
The issues with testing/coverage are largely due to people misunderstanding
what side-effects measuring code coverage can have, and therefore trying to
short-circuit the tests and only run the tests once.
I can get into quite a rant on this, but essentially,
I have seen simple code where people do not think threading would even be
involved, and the tests pass when instrumented and fail when not
instrumented... from this I concluded that if you have me or somebody worse
at coding than me on your team, you must always ensure that the tests are
run without coverage instrumentation.
I have seen simple code where the tests pass without instrumentation and
fail with instrumentation (and I'm not talking performance tests) 9 times
out of 10, when I looked into it the failure would be replicated by
switching to a different JVM... and when I looked at the code I would see
that both the pass and the fail were valid under the JVM spec... from this I
concluded that if you have me or somebody worse at coding than me on your
team, you must always ensure that the tests are run with coverage
instrumentation... and you probably want to also run the tests on a
different vendor JVM on a different CPU architecture (with or without
instrumentation)
Instrumentation with emma/cobertura/clover will catch, IMHO, about 80% of
the bugs due to people failing to understand how the JVM spec can re-order
operations and optimize code.
So my conclusions are that you always need to run the tests at least twice.
I agree that the current situation where running
mvn clean deply site-deploy
can result in the unit tests being run 10-15 times over is ridiculous...
hopefully some of the lifecycle-forking changes that are required to fix
this will be available in 3.x
I suspect that a lot of the fixes for this could be implemented in the 2.x
branch too, or even natively in the plugins (e.g. by having the reporting
plugins not fork the build, and not having @aggregator mojos)
-Stephen
2009/9/24 Stevo Slavić <ss...@gmail.com>
> 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.connolly@gmail.com> wrote:
>
> > 2009/9/23 Stephen Connolly <st...@gmail.com>:
> > > 2009/9/23 Thomas Sundberg <th...@agical.com>:
> > >> On Wed, Sep 23, 2009 at 11:22, Manuel Grau <ma...@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 <th...@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.sundberg@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.sundberg@agical.com
> > >> http://www.agical.com
> > >> Blog: http://thomassundberg.wordpress.com/
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: users-help@maven.apache.org
> > >>
> > >>
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
Re: Organise integration tests in a Maven project
Posted by Stevo Slavić <ss...@gmail.com>.
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.connolly@gmail.com> wrote:
> 2009/9/23 Stephen Connolly <st...@gmail.com>:
> > 2009/9/23 Thomas Sundberg <th...@agical.com>:
> >> On Wed, Sep 23, 2009 at 11:22, Manuel Grau <ma...@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 <th...@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.sundberg@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.sundberg@agical.com
> >> http://www.agical.com
> >> Blog: http://thomassundberg.wordpress.com/
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Organise integration tests in a Maven project
Posted by Stephen Connolly <st...@gmail.com>.
2009/9/23 Stephen Connolly <st...@gmail.com>:
> 2009/9/23 Thomas Sundberg <th...@agical.com>:
>> On Wed, Sep 23, 2009 at 11:22, Manuel Grau <ma...@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 <th...@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.sundberg@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.sundberg@agical.com
>> http://www.agical.com
>> Blog: http://thomassundberg.wordpress.com/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Organise integration tests in a Maven project
Posted by Stephen Connolly <st...@gmail.com>.
2009/9/23 Thomas Sundberg <th...@agical.com>:
> On Wed, Sep 23, 2009 at 11:22, Manuel Grau <ma...@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 <th...@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.sundberg@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.sundberg@agical.com
> http://www.agical.com
> Blog: http://thomassundberg.wordpress.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Organise integration tests in a Maven project
Posted by Thomas Sundberg <th...@agical.com>.
On Wed, Sep 23, 2009 at 11:22, Manuel Grau <ma...@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?
/Thomas
As a sidenote, I totally agree with the quote from Dijkstra.
>
> 2009/9/23 Thomas Sundberg <th...@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.sundberg@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.sundberg@agical.com
http://www.agical.com
Blog: http://thomassundberg.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Organise integration tests in a Maven project
Posted by Manuel Grau <ma...@gmail.com>.
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.
2009/9/23 Thomas Sundberg <th...@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.sundberg@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)