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.

2) I think there are use cases when we want to have the integration tests in
the same module as what they are testing. For example, take the case of an
ejb project. I think the project could have both unit tests and integration
tests in the same module. Functional tests is another matter and I'd usually
see them in a separate module altogether (as they usually require several
modules to be built).

ejb/
  src/
    main/
    test/
      java/ (unit tests - shouldn't be called java really)
      it/ (integration tests)

I have a use case for the daytrader build where I need to do this. I'd like
to have some it tests next to some unit tests. The reason I want them in the
same module is because I want to have 1 or 2 it tests to act as a quick
proof that the ejb code works. It's not meant to replace functional tests
which I'm also doing but in some other module.

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.

Note: the current it plugin is probably not correctly named as it makes
sense only for performing integration tests for m2 plugin.

WDYT?

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]





--

jvz.

Jason van Zyl
jason at maven.org
http://maven.apache.org

you are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.

  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to