You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Robert Mark Bram <ro...@gmail.com> on 2014/10/06 11:31:32 UTC
Running integration tests
Hi All,
A couple of questions about integration tests..
1) Default vs non-default plugins
I needed to include the maven-failsafe-plugin plugin to introduce
integration tests into my project, but I didn't need to introduce the
maven-surefire-plugin to my pom.xml for unit tests. Fair enough, but
how do I know which plugins are included by default?
2) Just run integration tests?
I can see that unit tests are all classes with names like *Test.java
and integration tests are all classes with names like IT.java. But mvn
verify and mvn test seem to run all tests (unit and integrations). Is
there a way to run just one or the other?
3) Run integration tests after compile?
The real reason for question 2 is that I wish to run integration tests
only after I have deployed the new application to ensure the
integration tests run on the server with the new content. Is there a
way to do this?
Thanks for any assistance!
Rob
:)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Running integration tests
Posted by Manfred Moser <ma...@mosabuam.com>.
You got it Robert..
Robert Mark Bram wrote on 07.10.2014 19:59:
> OK, this was very helpful too. In this case, I am working with a
> multi-module project and I decided it was best to add our selenium
> tests in a new project to keep them away from other project code. We
> have 13 pom.xml files, not counting the one I am adding. So this is my
> next challenge, to ensure I get this project executing after the
> others have done their job and deployed to the app server.
In order to make that happen you test module just has to declare a dependency to the ear or whatever is the final output that will be deployed and tested in the module. The reactor (e.g. multi module support in Maven) will then do the right thing.
manfred
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Running integration tests
Posted by Stephen Connolly <st...@gmail.com>.
Thanks Anders...
It can be hard to look that stuff on the phone...
I remember wanting to have a symmetry with the Surefire patterns of
Test*.java; *Test.java; *TestCase.java but I couldn't recall what I did for
the last one!
On 8 October 2014 07:19, Anders Hammar <an...@hammar.net> wrote:
> >
> > So failsafe will pickup
> >
> > ITblahblah.java
> > BlahblahIT.java
> >
> > And a third form that I forget
> >
>
> *ITCase.java
>
>
> http://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#includes
>
> /Anders
>
>
> >
> >
> > >
> > >
> > > > > 3) Run integration tests after compile?
> > > > > The real reason for question 2 is that I wish to run integration
> > tests
> > > > > only after I have deployed the new application to ensure the
> > > > > integration tests run on the server with the new content. Is there
> a
> > > > > way to do this?
> > >
> > > > Sounds like you should consult my answer to a related question:
> > > >
> > >
> >
> http://stackoverflow.com/questions/16935290/maven-deploy-webapp-to-tomcat-before-junit-test/16936585#16936585
> > >
> > > OK, this was very helpful too. In this case, I am working with a
> > > multi-module project and I decided it was best to add our selenium
> > > tests in a new project to keep them away from other project code. We
> > > have 13 pom.xml files, not counting the one I am adding. So this is my
> > > next challenge, to ensure I get this project executing after the
> > > others have done their job and deployed to the app server.
> >
> >
> > Dependencies will ensure sequencing of modules
> >
> >
> > >
> > > Why, sometimes I've believed as many as five impossible things before
> > > after-noon tea. Time for one more before I knock off at 5pm.
> > >
> > > Rob
> > > :)
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > <javascript:;>
> > > For additional commands, e-mail: users-help@maven.apache.org
> > > <javascript:;>
> > >
> > >
> >
> > --
> > Sent from my phone
> >
>
Re: Running integration tests
Posted by Anders Hammar <an...@hammar.net>.
>
> So failsafe will pickup
>
> ITblahblah.java
> BlahblahIT.java
>
> And a third form that I forget
>
*ITCase.java
http://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#includes
/Anders
>
>
> >
> >
> > > > 3) Run integration tests after compile?
> > > > The real reason for question 2 is that I wish to run integration
> tests
> > > > only after I have deployed the new application to ensure the
> > > > integration tests run on the server with the new content. Is there a
> > > > way to do this?
> >
> > > Sounds like you should consult my answer to a related question:
> > >
> >
> http://stackoverflow.com/questions/16935290/maven-deploy-webapp-to-tomcat-before-junit-test/16936585#16936585
> >
> > OK, this was very helpful too. In this case, I am working with a
> > multi-module project and I decided it was best to add our selenium
> > tests in a new project to keep them away from other project code. We
> > have 13 pom.xml files, not counting the one I am adding. So this is my
> > next challenge, to ensure I get this project executing after the
> > others have done their job and deployed to the app server.
>
>
> Dependencies will ensure sequencing of modules
>
>
> >
> > Why, sometimes I've believed as many as five impossible things before
> > after-noon tea. Time for one more before I knock off at 5pm.
> >
> > Rob
> > :)
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> <javascript:;>
> > For additional commands, e-mail: users-help@maven.apache.org
> > <javascript:;>
> >
> >
>
> --
> Sent from my phone
>
Re: Running integration tests
Posted by Stephen Connolly <st...@gmail.com>.
Then all I ask is you pay your newfound enlightenment forward...
With this information you can answer some maven newbie questions on the M/L
On Wednesday, 8 October 2014, Robert Mark Bram <ro...@gmail.com>
wrote:
> Thank you Stephen - this was very useful and came just when I am ready
> to start piecing together this level of detail.
>
> > > 1) Default vs non-default plugins
> > > suddenly a White Rabbit with pink eyes ran close by Alice
>
> So, what I understood from this trip down the rabbit-hole.
> - Maven defines various lifecycles.
> - Each lifecycle defines a list of phases.
> - Each phase will execute a list of goals (defined in plugins).
> - What specific goals get executed in each phase depends on the
> packaging defined for the pom.xml. Generally package defines what sort
> of artifact you are dealing with: jar, war, ear etc.
> - I am using ear packaging, so it binds the surefire:test goal to the
> test phase, but binds nothing to integration-test - which is why I
> need to add the failsafe plugin to my pom.xml. I didn't need to define
> a phase for it, because failsafe's default phase is integration-test.
>
> > > 2) Just run integration tests?
> > > I can see that unit tests are all classes with names like *Test.java
> > > and integration tests are all classes with names like IT.java. But mvn
> > > verify and mvn test seem to run all tests (unit and integrations). Is
> > > there a way to run just one or the other?
>
> So, going from the previous trip down the rabbit hole, I understand
> that when I run "mvn verify" I was seeing unit tests and integration
> tests being run because in order to get to the verify phase (where my
> integration tests should run from), it was running every phase before
> that - including the test phase (where unit tests are run).
>
> > tweaking of
> >
> http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#skipTests
> > should get you there!
>
> When I was running "mvn test", I was also seeing integration tests
> being run because I had named my integration test classes
> TestBlahBlahIt.java so they were being picked up by both the test and
> integration-test phases.
>
> So, I should more strictly follow the convention of
> - unit tests being Test*.java - and NOT including IT at the end.
> - integration tests being *.IT.java - and NOT starting with Test.
Or start with IT
So failsafe will pickup
ITblahblah.java
BlahblahIT.java
And a third form that I forget
>
>
> > > 3) Run integration tests after compile?
> > > The real reason for question 2 is that I wish to run integration tests
> > > only after I have deployed the new application to ensure the
> > > integration tests run on the server with the new content. Is there a
> > > way to do this?
>
> > Sounds like you should consult my answer to a related question:
> >
> http://stackoverflow.com/questions/16935290/maven-deploy-webapp-to-tomcat-before-junit-test/16936585#16936585
>
> OK, this was very helpful too. In this case, I am working with a
> multi-module project and I decided it was best to add our selenium
> tests in a new project to keep them away from other project code. We
> have 13 pom.xml files, not counting the one I am adding. So this is my
> next challenge, to ensure I get this project executing after the
> others have done their job and deployed to the app server.
Dependencies will ensure sequencing of modules
>
> Why, sometimes I've believed as many as five impossible things before
> after-noon tea. Time for one more before I knock off at 5pm.
>
> Rob
> :)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: users-help@maven.apache.org
> <javascript:;>
>
>
--
Sent from my phone
Re: Running integration tests
Posted by Robert Mark Bram <ro...@gmail.com>.
Thank you Stephen - this was very useful and came just when I am ready
to start piecing together this level of detail.
> > 1) Default vs non-default plugins
> > suddenly a White Rabbit with pink eyes ran close by Alice
So, what I understood from this trip down the rabbit-hole.
- Maven defines various lifecycles.
- Each lifecycle defines a list of phases.
- Each phase will execute a list of goals (defined in plugins).
- What specific goals get executed in each phase depends on the
packaging defined for the pom.xml. Generally package defines what sort
of artifact you are dealing with: jar, war, ear etc.
- I am using ear packaging, so it binds the surefire:test goal to the
test phase, but binds nothing to integration-test - which is why I
need to add the failsafe plugin to my pom.xml. I didn't need to define
a phase for it, because failsafe's default phase is integration-test.
> > 2) Just run integration tests?
> > I can see that unit tests are all classes with names like *Test.java
> > and integration tests are all classes with names like IT.java. But mvn
> > verify and mvn test seem to run all tests (unit and integrations). Is
> > there a way to run just one or the other?
So, going from the previous trip down the rabbit hole, I understand
that when I run "mvn verify" I was seeing unit tests and integration
tests being run because in order to get to the verify phase (where my
integration tests should run from), it was running every phase before
that - including the test phase (where unit tests are run).
> tweaking of
> http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#skipTests
> should get you there!
When I was running "mvn test", I was also seeing integration tests
being run because I had named my integration test classes
TestBlahBlahIt.java so they were being picked up by both the test and
integration-test phases.
So, I should more strictly follow the convention of
- unit tests being Test*.java - and NOT including IT at the end.
- integration tests being *.IT.java - and NOT starting with Test.
> > 3) Run integration tests after compile?
> > The real reason for question 2 is that I wish to run integration tests
> > only after I have deployed the new application to ensure the
> > integration tests run on the server with the new content. Is there a
> > way to do this?
> Sounds like you should consult my answer to a related question:
> http://stackoverflow.com/questions/16935290/maven-deploy-webapp-to-tomcat-before-junit-test/16936585#16936585
OK, this was very helpful too. In this case, I am working with a
multi-module project and I decided it was best to add our selenium
tests in a new project to keep them away from other project code. We
have 13 pom.xml files, not counting the one I am adding. So this is my
next challenge, to ensure I get this project executing after the
others have done their job and deployed to the app server.
Why, sometimes I've believed as many as five impossible things before
after-noon tea. Time for one more before I knock off at 5pm.
Rob
:)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Running integration tests
Posted by Stephen Connolly <st...@gmail.com>.
On 6 October 2014 10:31, Robert Mark Bram <ro...@gmail.com> wrote:
> Hi All,
>
> A couple of questions about integration tests..
>
>
> 1) Default vs non-default plugins
> I needed to include the maven-failsafe-plugin plugin to introduce
> integration tests into my project, but I didn't need to introduce the
> maven-surefire-plugin to my pom.xml for unit tests. Fair enough, but
> how do I know which plugins are included by default?
>
> suddenly a White Rabbit with pink eyes ran close by Alice
In your pom.xml there is a xml node /project/packaging that specifies the
lifecycle for your project.
You may not have set the value to anything, as the default if unspecified
is: jar
> There was nothing so very remarkable in that; nor did Alice think it so
very much out of the way to hear the Rabbit say to itself "Oh dear! Oh
dear! I shall be too late!"
Maven consults all the registered extensions and the core functionality to
see what lifecycles are registered for the packaging of the module it is
building.
In general it will end up here:
https://github.com/apache/maven/blob/276c7636d342f6d01353ae862b56fa89614b17a9/maven-core/src/main/resources/META-INF/plexus/components.xml#L33
> but, when the Rabbit actually took a watch out of its waistcoat-pocket,
and looked at it, and then hurried on, Alice started to her feet, for it
flashed across her mind that she had never before seen a rabbit with either
a waistcoat-pocket, or a watch to take out of it, and burning with
curiosity, she ran across the field after it, and was just in time to see
it pop down a large rabbit-hole under the hedge.
Once Maven has determined the lifecycle(s) that apply to your module, it
then looks up the phases and goals that you specified when invoking Maven.
>From this list of phases and goals it starts to construct the build plan...
Conceptually, at the start the build plan is just the list of phases to
execute.
So for example you type: `mvn clean install clean deploy site-deploy`
Then Maven says, ok clean comes from the `clean` lifecycle, and it is the
second phase... so we will start off with: pre-clean, clean
Next we need install, so that's from the default lifecycle and we will add
in the phases: validate, initialize, generate-sources, process-sources,
generate-resources, process-resources, compile, process-classes,
generate-test-sources, process-test-sources, generate-test-resources,
process-test-resources, test-compile, process-test-classes, test,
prepare-package, package, pre-integration-test, integration-test,
post-integration-test, verify, install
Then we need another clean... at this point our list will be looking like:
pre-clean, clean, validate, initialize, generate-sources, process-sources,
generate-resources, process-resources, compile, process-classes,
generate-test-sources, process-test-sources, generate-test-resources,
process-test-resources, test-compile, process-test-classes, test,
prepare-package, package, pre-integration-test, integration-test,
post-integration-test, verify, install, pre-clean, clean
Then we need to go all the way up to deploy... so we'll have: pre-clean,
clean, validate, initialize, generate-sources, process-sources,
generate-resources, process-resources, compile, process-classes,
generate-test-sources, process-test-sources, generate-test-resources,
process-test-resources, test-compile, process-test-classes, test,
prepare-package, package, pre-integration-test, integration-test,
post-integration-test, verify, install, pre-clean, clean, validate,
initialize, generate-sources, process-sources, generate-resources,
process-resources, compile, process-classes, generate-test-sources,
process-test-sources, generate-test-resources, process-test-resources,
test-compile, process-test-classes, test, prepare-package, package,
pre-integration-test, integration-test, post-integration-test, verify,
install, deploy
And finally we need to run up the site lifecycle as far as site-deploy...
so now the complete list of phases to execute in order are: pre-clean,
clean, validate, initialize, generate-sources, process-sources,
generate-resources, process-resources, compile, process-classes,
generate-test-sources, process-test-sources, generate-test-resources,
process-test-resources, test-compile, process-test-classes, test,
prepare-package, package, pre-integration-test, integration-test,
post-integration-test, verify, install, pre-clean, clean, validate,
initialize, generate-sources, process-sources, generate-resources,
process-resources, compile, process-classes, generate-test-sources,
process-test-sources, generate-test-resources, process-test-resources,
test-compile, process-test-classes, test, prepare-package, package,
pre-integration-test, integration-test, post-integration-test, verify,
install, deploy, pre-site, site, post-site, site-deploy
> In another moment down went Alice after it, never once considering how in
the world she was to get out again.
Now Maven needs to decide exactly what it should do for each of those
phases.
So it starts by considering the default bindings: These again are
determined by the packaging. In the case of the jar packaging from core
that is defined here:
https://github.com/apache/maven/blob/276c7636d342f6d01353ae862b56fa89614b17a9/maven-core/src/main/resources/META-INF/plexus/default-bindings.xml
So everywhere that Maven sees the `test` phase it will add a binding of
surefire:
https://github.com/apache/maven/blob/276c7636d342f6d01353ae862b56fa89614b17a9/maven-core/src/main/resources/META-INF/plexus/default-bindings.xml#L82
the binding defined the default plugin version but if you specify a
different plugin version in your pom then the default is overridden.
Next Maven looks at the effective pom for your project to see if there are
any executions that are bound to phases.
At the end of this process, maven now has a list of ordered plugin goal
executions... and away it goes
>
> 2) Just run integration tests?
> I can see that unit tests are all classes with names like *Test.java
> and integration tests are all classes with names like IT.java. But mvn
> verify and mvn test seem to run all tests (unit and integrations). Is
> there a way to run just one or the other?
>
tweaking of
http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#skipTests
should get you there!
>
> 3) Run integration tests after compile?
> The real reason for question 2 is that I wish to run integration tests
> only after I have deployed the new application to ensure the
> integration tests run on the server with the new content. Is there a
> way to do this?
>
>
Sounds like you should consult my answer to a related question:
http://stackoverflow.com/questions/16935290/maven-deploy-webapp-to-tomcat-before-junit-test/16936585#16936585
> Thanks for any assistance!
>
> Rob
> :)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Running integration tests
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi Robert,
On 10/6/14 11:31 AM, Robert Mark Bram wrote:
> Hi All,
>
> A couple of questions about integration tests..
>
>
> 1) Default vs non-default plugins
> I needed to include the maven-failsafe-plugin plugin to introduce
> integration tests into my project, but I didn't need to introduce the
> maven-surefire-plugin to my pom.xml for unit tests. Fair enough, but
> how do I know which plugins are included by default?
This can be read here:
http://maven.apache.org/ref/3.1.1/maven-core/default-bindings.html
There you can see for which packaging type which plugins are bound to
the particular life cycle phases...
>
> 2) Just run integration tests?
> I can see that unit tests are all classes with names like *Test.java
> and integration tests are all classes with names like IT.java. But mvn
> verify and mvn test seem to run all tests (unit and integrations). Is
> there a way to run just one or the other?
mvn test
should not run integration tests...if it will so you have configured it
wrong and not used maven-failsafe-plugin and bound to the wrong life
cycle...cause the phases: pre-integration-test, integration-test and
post-integration-test ran after package phase...
So they will only be reached if you do
mvn verify
If you like to run only integration tests you can do this via
configuring maven-surefire-plugin with a parameter skip...
mvn -Dskip.unit.tests=true verify
which will skip the unit tests but run the integration tests...
>
> 3) Run integration tests after compile?
> The real reason for question 2 is that I wish to run integration tests
> only after I have deployed the new application to ensure the
> integration tests run on the server with the new content. Is there a
> way to do this?
Based on the life cylce this is guaranteed...
>
> Thanks for any assistance!
You're welcome...
Kind regards
Karl-Heinz Marbaise
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org