I worry a bit about mixing unit and integration tests generally... maybe we have the recommended case for them go into src/integration-test/java or something along those lines...
logically the structure src/test/java and src/test/it doesn't do it for me since it tests are probably written in java anyway, so that kinda breaks the spirit of 'src'/'type'/'language' convention we kind of have going.. as for the rest of it, I like adding the phases...I remember the last time we talked about this there was a bit of concern that arose based on 'where do we stop?' in supporting different testing strategies...integration tests make sense to support in the lifecycle, but should integration tests embody the deployment of a generated ear and automated tests against a container started by the build system? or the running of tests generated by something like the axistools plugin that can reach out and test connectivity/functionality for a webservices client? I think there was general consensus on the integration testing phase, but some question on the later type of testing...and I think the formalization of the integration testing into maven then was delayed to consider if these other types of testing might prompt some reworking of the existing framework... there, I think I captured the jist of that discussion, it was on irc a few months ago.. jesse On 12/28/05, Vincent Massol <[EMAIL PROTECTED]> wrote: > > > > > -----Original Message----- > > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > > Sent: mercredi 28 décembre 2005 19:51 > > To: Maven Developers List > > Subject: Re: [discussion] Integration testing location > > > > Vincent Massol wrote: > > > Hi there, > > > > > > I'd like to continue the discussion about integration testing (see > > > http://docs.codehaus.org/display/MAVEN/Testing+Strategies). Here are > > some > > > topics on which I'd like to get your opinion: > > > > > > 1) Need for a pre/post phase to integration-test. See > > > http://jira.codehaus.org/browse/MNG-1880. > > > > Is this going to be a general pattern in that we might want to decorate > > the phases. I like having the concrete phases but maybe for genericity > > we need to allow the decoration of each of our concrete phases or we may > > simply run into further limitations that require changes to lifecycles. > > > > > I guess this could be implemented very quickly. Isn't it just a matter > > of > > > adding 2 new phases in components.xml? > > > > > > Do we all agree on the need for this? > > > > I think a general decoration mechanism would be useful. Even though this > > could be somewhat unstructured I think the utility gained is probably > > more important. So I would be > > > > +1 > > > > Unless we could think of some serious downsides. Can't think of any off > > the top of my head. > > +1 for implicit pre/post phases to for all phases. > > [snip] > > > > I don't think the surefire plugin support this right now. The problem > is > > > that it's using configuration elements defined outside of the <plugin> > > > section in the pom so I don't think it's currently possible to have > > several > > > executions of it with different configurations. > > > > Right, the test classes directory is pulled from the <build/> element so > > we would need to do something there for integration test classes to be > > picked up. > > > > > Another option is to have an it plugin which is basically the same as > > the > > > surefire plugin but bound at different phases and using different > > > configuration elements. > > > > > > Which solution do we want? > > > > What about a parallel for integration tests like we have for unit tests? > > > > If we are going to consider integration testing on the same level as > > unit testing then we might want to add an integration source setting to > > the <build/> element because we will need to compile the integration > > tests which will be in a different directory and they will need to be > > output to a different directory so that surefire can pick them up. So > > there will be some values that will need to be accessed by several mojos > > to make this work. So for each element we have in the POM and each step > > in the lifecycle we have for testing we need for integration testing. > > Right. This is a good thing to do I think. > > Thanks > -Vincent > > > > > > > > ___________________________________________________________________________ > Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les > tarifs exceptionnels pour appeler la France et l'international. > Téléchargez sur http://fr.messenger.yahoo.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom
