A common pattern in Maven is to put integration tests into their own module(s). For multi-module projects this actually makes a lot of sense, because integration tests will often depend on more than one module.
Cheers, Peter Russel Winder-4 wrote: > > Steve, > > Your email must have arrived just as I was sending my last one . . . ! > > On Mon, 2009-08-03 at 15:09 -0400, Steve Appling wrote: > [ . . . ] >> Traditionally in Maven and in Gradle, tests were run against the classes >> dir >> because passing the test was a precondition for building the jar (jar >> depends on >> test). This happens to have just changed in Gradle (over the weekend). >> Jar no >> longer depends on test and there is a set of new tasks starting with >> "build" >> that will both test and compile. > > I think there is a strong role for this pre-packaging testing. I have > no problem with it. The problem I have is that Maven, Eclipse, IntelliJ > IDEA, and I fear Gradle, only support this mode of testing. Integration > and system testing are not actually supported at all. Maven has an > integration-test phase but the classpath used is basically just the same > as test which is fundamentally useless. As for Gradle, I suspect I need > to RTFM :-) > >> Test, however, is still running out of the classes dir and not off of the >> jar. >> I'm not convinced that this is wrong, but we should allow you the >> flexibility to >> change it. The JavaPlugin adds the classes dir to the testCompile >> configuration >> (see JavaPlugin.java line 245 in the trunk). The DependencyHandler >> doesn't have >> a good way of removing dependencies only adding them. Perhaps you could >> replace >> the testCompile configuration with a copy filtered using one of the >> filtering >> forms of Configuration.copy. There needs to be a better way of >> customizing >> things like this. > > Actually I am not sure I want to change the test phase, what I want to > do is have a proper integration/system test phase (which Maven doesn't > have despite the integration-test phase). If I look at what I have as > unit tests in Gant, it is clear that some are unit tests in the classic > sense, and some are integration tests. The standard model has forced me > to lump them all together and it is this that is causing me the > problems. > > I need to separate out the real unit tests (which can happily be > compiled in the classic "against the directory" mode) from what are > really integration and system test, for which Eclipse, IntelliJ IDEA, > Maven, and I suspect Gradle, have no real support. > > -- > Russel. > ============================================================================= > Dr Russel Winder Partner > xmpp: [email protected] > Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 > 41 Buckmaster Road, f: +44 8700 516 084 voip: > sip:[email protected] > London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder > > > -- View this message in context: http://www.nabble.com/Lifecycle-phases-tp24795613p24813720.html Sent from the gradle-user mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
