You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Vincent Massol <vm...@pivolis.com> on 2006/01/09 11:20:01 UTC

RE: [codehaus-confluence] Maven: best practices - testing strategies (comment added)

Hi Alex,

 

I'm answering here as I'm sure others will have ideas too about this. 

 

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.

 

You'd be free to put whatever junit tests you want in src/test/unit so you
could put cactus tests there if you wanted (even though the logical place
for them would be src/test/integration). The only impact it has is that your
tests would be called at a certain point in the lifecycle.

 

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). The
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.

 

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.

 

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.

 

WDYT?

 

Thanks

-Vincent

 

 

  _____  

From: confluence@codehaus.org [mailto:confluence@codehaus.org] 
Sent: lundi 9 janvier 2006 10:56
To: vmassol@codehaus.org
Subject: [codehaus-confluence] Maven: best practices - testing strategies
(comment added)

 


Comment Added : MAVEN <http://docs.codehaus.org/display/MAVEN>  : Re:
<http://docs.codehaus.org/display/MAVEN/best+practices+-+testing+strategies?
focusedCommentId=42545#comment-42545>  best practices - testing strategies 

best
<http://docs.codehaus.org/display/MAVEN/best+practices+-+testing+strategies?
focusedCommentId=42545#comment-42545>  practices - testing strategies
commented on by Alexandre Russel <http://docs.codehaus.org/display/~arussel>
(Jan 09, 2006). 

Comment:

I consider that Cactus test on my ejb are unit test. Some, because done
inside a container will consider it integration test even if a test affect
only one ejb at a time. I think the line between unit/functional/integration
is sometimes to thin to base the directory structure on it. Why not have a
test directory with inside it a separation by type of test such as:
test
 |_junit
 |_cactus
 |_httpUnit
 |_JMeter
 |_...
and so on. The surefire plugin could then call the plugin responsible for
cactus, httpUnit....test. It makes the structure clear and simple and the
possibility to add test easy.

 


  <http://docs.codehaus.org/images/border/spacer.gif> 

Powered by
<http://www.atlassian.com/software/confluence/default.jsp?clicked=footer>
Atlassian Confluence (Version: 2.1.1 Build:#406 Dec 23, 2005) -
<http://jira.atlassian.com/secure/BrowseProject.jspa?id=10470> Bug/feature
request

 <http://docs.codehaus.org/users/viewnotifications.action> Unsubscribe or
edit your notifications preferences