[ http://jira.codehaus.org/browse/MNG-591?page=comments#action_42969 ]
Brett Porter commented on MNG-591: ---------------------------------- Currently, we have "test" which exists before package, and has its own source code and resources, but its classes are not processed like a normal build. Then we have integration-test and verify which occur after packaging, but before installation, and don't have any sources of their own. We are also missing the case where you might have intensive tests that you don't want to run during development. I still think these belong before install, and can be enabled in an integration environment using profiles instead. Can we think of better ways to specify test sets than this? What I'm thinking is: - we have unit-test, functional-test (both before package), and integration-test - each has an identical lifecycle to main (generate/process-sources/resources, compile, process-classes) - it is up to the user to use profiles to apply things they want in dev or not I think the itest plugin IDEA above is good (could we use the verifier plugin?) However, I don't think we should have to rely on it being installed before it is tested. Maybe that's not a big deal, esp. since the reactor should be able to take care of it, however I feel there is some merit to keeping it all together, especially as IDEs might deal with it better that way if they have plugins for the testing framework. Of course it is still possible to have a separate test suite, using dependencies to get the code to test. I'm still a little uncertain how we might do something like cactus in the same as m1. Perhaps it could fork it's own lifecycle to compile it's special sources, then package them up, deploy, and run tests? It could map flat to the integration-test-* stuff, but then if you have >1 the order is whacky and you also end up having a cactus:compile goal that has to extend AbstractCompilerMojo which is not ideal. > Integration tests lifecycle > --------------------------- > > Key: MNG-591 > URL: http://jira.codehaus.org/browse/MNG-591 > Project: Maven 2 > Type: Improvement > Reporter: Kenney Westerhof > Fix For: 2.0-beta-1 > > > I'm trying to do an integration test that depends on a war/ear to be deployed. > What i'm missing is: > - integration-test-compile stage and/or: > - a way to specify an integrationTestSourceDirectory or multiple > testSourceDirectories in the pom > I can't put the test sources in src/test/java because then surefire will run > them in the test stage, when > there's no artifact to deploy yet. > [Btw, I'm doing this while creating a cactus plugin, for the moment using > cargo in the TestSuite itself to deploy.] > The idea is that the integration test sources go in src/itest/*; that there > be a integration-test-compile, > integration-test-package and/or integration-test-appdeploy[or something] and > that surefire > is also bound to integration-test. > Maybe something can be done using the src/test/project/some-project/.... > approach seen in > maven-javadoc-plugin, maven-site-plugin and maven-eclipse-plugin (i'd like to > see some of that > standardized anyway to allow plugin testing generally - which can also be > seen as integration testing). > Thoughts, comments, approaches? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
