Vincent Massol wrote: > There's still a need to define the different types of tests. What we're > trying to do in m2 is find generic phases that work for all types of build > actions. The mapping between the phases and the tools is done separately. So > we still need to define the unit, integration and functional tests phases, > independently of what tools are used to execute them. This is required > because we need to know when the tests should be triggered in the lifecycle.
+1. I recall doing some work on this, getting some feedback in the original JIRA, and linking some discussion. Has anyone dug that up? Maybe the names need to be more specific. While everyone recognises "integration testing", everyone also thinks it is something different :) > Now that said we could have specific plugins for each framework (cactus, > httpunit, etc) but I think we'd loose some flexibility if we had to code > those. Instead what I'm suggesting here is that there's no need for those > plugins (note: we could still have them but they would only be convenience > plugins, used to fill the test classpath automatically for example). I agree. > tests are junit tests and thus would be run by the generic surefire plugin. > What you would need though is the ability to do things before and after the > tests (like deploy J2EE modules to a container, start the container, stop > it, etc). This is why there are before-integration-test and > after-integration-test phases defined. +1. The phases of testing need to be identified and applied consistently too (compiling, resources, etc). Integration testing probably needs a packaging step. > For jmeter it's different as it's not made of junit tests so you'd need a > jmeter test runner in the form of a plugin. Yep, we need to add this ability to the surefire plugin. I think it is already possible - but would need to check and it could certainly use some refactoring. Basically the api/provider model: surefire is the api, surefire booter is surefire-junit I think, then there is surefire-testng, surefire-cactus (if any different to straight junit), surefire-jmeter, etc. To take a tangent... That might expose a limitation in the output of the plugin though - or do we let it do reporting in its own way? So most will spit out "junit style xml report", "junit style txt report" for pass/fail. Then maybe jmeter spits out a different xml report for transforming into the site. I think in contrast, the reporting plugins should not be a provider style - we should make the current "surefire report" the "test results report", and have different reporting plugins for jmeter, etc. Some of the handling may go in surefire itself so that various reports can use it - eg I'm sure cactus is still "different but similar" to the junit - so would use some of the code but add some of its own. > All that said, I think we should support different executions for the > surefire plugin so that it should be possible to define arbitrary test > directories should the need arise. This is tied in to the ability to do likewise with compile/resources. We should push this to the 2.1 discussion on changing the execution model. I think we actually need a single build to be able to re-execute the lifecycle in a different way. - Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
