I think Arnaud's advice is right if you're going to keep one project for everything - set up the profiles. You may need to re-arrange the source tree a little bit, though - looks like you have several different source trees, one for each category of tests. I'm not sure how the surefire plugin will respond to having multiple source trees (the config section only takes one location), so if it complains, you'll probably need to move everything into e.g. src/test/java (/functional, /unit, etc.).
Alternatively the separate project approach would let you configure the surefire plugin for each type of unit test. You can by default skip unit tests in the functional/integration/etc. projects with <skip>true</skip> in the configuration of the plugin. If you make them child projects to the main, you can even inherit all the project properties/dependencies/etc. and have a really simple pom for each category of tests. Something like: computas-Eass-Main/pom.xml (type pom) \-- computas-Eass/pom.xml (where all your source code is) \-- functional-Tests/pom.xml (inherits from Main/parent project to share all deps etc., set to skip unit tests by default) \-- unit-Tests/pom.xml (also inherits parent properties, but set to run tests by default) etc. This will still relate the project/tests hierarchically and is (I think) fairly elegant as it allows fine-tuning of when to run which type of test and won't duplicate any effort (you're inheriting the parent project's properties). Dave On 9/4/07, Insitu <[EMAIL PROTECTED]> wrote: > > Kjetil Kjernsmo <[EMAIL PROTECTED]> writes: > > > > > Looking through the source tree, I see that we do allready have a naming > > convention, but in terms of directory naming: > > > > test: > > functional/ > > integration/ > > performance/ > > unit/ > > > > where a test may have a path like: > > > test/integration/source/com/computas/eass/server/persistence/TestServiceProvider.java > > where the test/integration/source is not part of the package name. The > tests > > to be run in the test phase are in unit/, the tests for the integration > test > > phase is also well named. > > > > I suppose this is somewhat contrary to convention, so the question is if > I > > should rename things or configure things to use these subdirs? > > > > > >> You could also create a > >> separate project for the heavy-handed ones and only build that test > suite > >> manually as needed. > > > > Right. My boss mentioned that, but I felt that it was a bit inelegant, > and he > > is not very experienced with Maven either. Wouldn't it be nice to have a > > separate lifecycle phase for stuff like this? > > > > > Maybe you could use two features peculiar to maven to achieve what you > want within the confine of a single project (although I think moving > integration tests out to another project is a good idea): > 1. define a profile for each different kind of test you want to run: > perf, func, unit... > 2. in each profile, configure different set of test executions. this > can be done by configuring surefire plugin (see > http://maven.apache.org/plugins/maven-surefire-plugin/, it has a > zillion parameters to play with). If you use testNG, you can > define different test groups to be executed in each profile, if > you use Junit, you can include/exclude test files (you can also do > that with testNG of course). > 3. configure the basic execution of surefire (ie. the one that gets > executed always) to just run unit tests. > > Then running your tests is a matter of invoking maven with the right > profile(s): > > mvn -Pfunc-test > or > mvn -Pperf-test > or even > mvn -Pfunc-test -Pperf-test > > HTH > -- > OQube < software engineering \ génie logiciel > > Arnaud Bailly, Dr. > \web> http://www.oqube.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
