You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Stephen Colebourne <sc...@joda.org> on 2013/04/30 13:11:36 UTC

Testing jar files instead of class files

I would like to be able to achieve the following using two command
line invocations:
- build and install jar files using "mvn install"
- run tests again, but against the installed jar files

The rationale is that the first mvn run will only run "unit" tests
(using test groups in TestNG), whereas the second mvn run would run
all tests, including "slow" and "database" tests. In reality, both
would be run from a CI server rather than a developer desktop.

Clearly, the first mvn run is easy (I have that working). But I cannot
see a way to run a mvn command that executes the tests against the
installed jar files.

The project is a multi-module project. Moving tests into a separate
"testing only" project is not an acceptable approach. Running the
slow/database tests as part of a single mvn run is not an acceptable
approach.

thanks for any thoughts or hyperlinks.
Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Testing jar files instead of class files

Posted by Stephen Connolly <st...@gmail.com>.
On 30 April 2013 13:20, Stephen Connolly <st...@gmail.com>wrote:

> Well how I normally do something like that is I put the failsafe execution
> in a profile, which by convention is called `run-its`
>
> So to build everything and install in the local repository cache:
>
> mvn install
>
> To build everything and install in the local repository cache with
> integration tests run:
>
> mvn -P+run-its install
>
> The second invokation will also rebuild the artifacts.
>
> Note I typically will have the release profile activate the integration
> tests also such that the integration tests are run on all release artifacts
> always.
>
> If, however, you want to be able to test the build artifacts without
> rebuilding them, then you really just need to factor the tests into a
> separate module and just run that module.
>
> So, you would have a separate module called integration-tests that has its
> tests added via the run-its profile
>
> mvn install
>
> will install everything (including the dummy integration-tests module)
>
> mvn -Prun-its -pl integration-tests verify
>
> will just run the integration tests module with the integration test
> profile added (so that this time the integration tests are run)
>

The advantage of this way is that you are letting people who are on the
Maven way continue the Maven way

e.g. if I go from the root:

mvn -Prun-its verify

It will do what it is supposed to do: build everything and run the
integration tests

and you are still able to do what you want, all from the same set of poms
and all without having to do anything other than standard maven patterns


>
>
> On 30 April 2013 12:48, Stephen Colebourne <sc...@joda.org> wrote:
>
>> On 30 April 2013 12:28, Stephen Connolly
>> <st...@gmail.com> wrote:
>> > What you actually want to do is run your second set of tests after the
>> > 'package' phase and before the 'install' phase. There is only the
>> 'deploy'
>> > phase after the 'install' phase so there would be no scope to run tests
>> > after the 'install' phase.
>>
>> Thanks for the suggestion, but my question is around doing this in two
>> separate command line invocations, not one.
>>
>> Iin a large multi-module build, I need to complete the full install
>> for all modules (for speed). Only at that point do I want to stop and
>> separately (perhaps on demand) run the additional tests.
>>
>> Unless what you're indicating is a way to run the second maven build
>> without running the phases before integration-test?
>>
>> Stephen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>

Re: Testing jar files instead of class files

Posted by Stephen Connolly <st...@gmail.com>.
Well how I normally do something like that is I put the failsafe execution
in a profile, which by convention is called `run-its`

So to build everything and install in the local repository cache:

mvn install

To build everything and install in the local repository cache with
integration tests run:

mvn -P+run-its install

The second invokation will also rebuild the artifacts.

Note I typically will have the release profile activate the integration
tests also such that the integration tests are run on all release artifacts
always.

If, however, you want to be able to test the build artifacts without
rebuilding them, then you really just need to factor the tests into a
separate module and just run that module.

So, you would have a separate module called integration-tests that has its
tests added via the run-its profile

mvn install

will install everything (including the dummy integration-tests module)

mvn -Prun-its -pl integration-tests verify

will just run the integration tests module with the integration test
profile added (so that this time the integration tests are run)


On 30 April 2013 12:48, Stephen Colebourne <sc...@joda.org> wrote:

> On 30 April 2013 12:28, Stephen Connolly
> <st...@gmail.com> wrote:
> > What you actually want to do is run your second set of tests after the
> > 'package' phase and before the 'install' phase. There is only the
> 'deploy'
> > phase after the 'install' phase so there would be no scope to run tests
> > after the 'install' phase.
>
> Thanks for the suggestion, but my question is around doing this in two
> separate command line invocations, not one.
>
> Iin a large multi-module build, I need to complete the full install
> for all modules (for speed). Only at that point do I want to stop and
> separately (perhaps on demand) run the additional tests.
>
> Unless what you're indicating is a way to run the second maven build
> without running the phases before integration-test?
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: Testing jar files instead of class files

Posted by Stephen Colebourne <sc...@joda.org>.
On 30 April 2013 12:28, Stephen Connolly
<st...@gmail.com> wrote:
> What you actually want to do is run your second set of tests after the
> 'package' phase and before the 'install' phase. There is only the 'deploy'
> phase after the 'install' phase so there would be no scope to run tests
> after the 'install' phase.

Thanks for the suggestion, but my question is around doing this in two
separate command line invocations, not one.

Iin a large multi-module build, I need to complete the full install
for all modules (for speed). Only at that point do I want to stop and
separately (perhaps on demand) run the additional tests.

Unless what you're indicating is a way to run the second maven build
without running the phases before integration-test?

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Testing jar files instead of class files

Posted by David Evans <da...@evans6.me.uk>.

Regards

D. E. 

> On 22 Aug 2014, at 20:28, Maxime Gréau <gr...@gmail.com> wrote:
> 
> Hello,
> 
> This is exactly what I want to do.
> Is it the bug you are talking about ?
> https://jira.codehaus.org/browse/SUREFIRE-855
> 
> Regards
> Maxime Gréau.
> 
> 
> 2013-04-30 13:28 GMT+02:00 Stephen Connolly <stephen.alan.connolly@gmail.com
>> :
> 
>> Well just to put this into context.
>> 
>> What you actually want to do is run your second set of tests after the
>> 'package' phase and before the 'install' phase. There is only the 'deploy'
>> phase after the 'install' phase so there would be no scope to run tests
>> after the 'install' phase.a
>> 
>> If you look at the lifecycle, you will see the handy:
>> 
>> 'integration-test'
>> and
>> 'verify'
>> 
>> phases.
>> 
>> Now use of these phases is slightly different. Because you actually *never*
>> want to type "mvn integration-test" and any time you think you do, you
>> should actually type "mvn verify" in its place.
>> 
>> The reason for this is that the "pre-integration-test" and
>> "post-integration-test" phases are designed to allow setting up and tearing
>> down the integration test environment, and, despite their names, the
>> post-integration-test phase is *not* a finally block. So you need to be
>> careful when binding plugins to the integration-test phase that such
>> plugins *never* fail the build...
>> 
>> At this point we have the Maven Failsafe Plugin enter the fray... this has
>> two goals: failsafe:integration-test and failsafe:verify which, by default,
>> bind to the integration-test and verify phases respectively.
>> 
>> The `failsafe:integration-test` goal will run integration tests, but never
>> fails the build.
>> The `failsafe:verify` goal will check the results of
>> `failsafe:integration-test` and fail the build if the tests fail.
>> 
>> Thus you should be able to add failsafe to the mix by just adding
>> 
>> <plugin>
>> <artifactId>maven-failsafe-plugin</artifactId>
>> <executions>
>> <execution>
>> <goals>
>> <goal>integration-test</goal>
>> <goal>verify</goal>
>> </goals>
>> </execution>
>> </executions>
>> </plugin>
>> 
>> Now since failsafe is running after the `package` phase, it *should* be
>> using the project artifact in place of target/classes *when* executed after
>> the `package` phase... as all plugins should do... *but* I suspect there is
>> a bug in failsafe that causes it to explicitly add target/classes.
>> 
>> TL;DR it should be Maven Failsafe Plugin that gives this feature *but* I
>> suspect there is a bug in that plugin that is causing it to use the
>> directory in place of the .jar.
>> 
>> Kristian, can you confirm my summary?
>> 
>> -Stephen
>> 
>> 
>>> On 30 April 2013 12:11, Stephen Colebourne <sc...@joda.org> wrote:
>>> 
>>> I would like to be able to achieve the following using two command
>>> line invocations:
>>> - build and install jar files using "mvn install"
>>> - run tests again, but against the installed jar files
>>> 
>>> The rationale is that the first mvn run will only run "unit" tests
>>> (using test groups in TestNG), whereas the second mvn run would run
>>> all tests, including "slow" and "database" tests. In reality, both
>>> would be run from a CI server rather than a developer desktop.
>>> 
>>> Clearly, the first mvn run is easy (I have that working). But I cannot
>>> see a way to run a mvn command that executes the tests against the
>>> installed jar files.
>>> 
>>> The project is a multi-module project. Moving tests into a separate
>>> "testing only" project is not an acceptable approach. Running the
>>> slow/database tests as part of a single mvn run is not an acceptable
>>> approach.
>>> 
>>> thanks for any thoughts or hyperlinks.
>>> Stephen
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Testing jar files instead of class files

Posted by Maxime Gréau <gr...@gmail.com>.
Hello,

This is exactly what I want to do.
Is it the bug you are talking about ?
https://jira.codehaus.org/browse/SUREFIRE-855

Regards
Maxime Gréau.


2013-04-30 13:28 GMT+02:00 Stephen Connolly <stephen.alan.connolly@gmail.com
>:

> Well just to put this into context.
>
> What you actually want to do is run your second set of tests after the
> 'package' phase and before the 'install' phase. There is only the 'deploy'
> phase after the 'install' phase so there would be no scope to run tests
> after the 'install' phase.
>
> If you look at the lifecycle, you will see the handy:
>
> 'integration-test'
> and
> 'verify'
>
> phases.
>
> Now use of these phases is slightly different. Because you actually *never*
> want to type "mvn integration-test" and any time you think you do, you
> should actually type "mvn verify" in its place.
>
> The reason for this is that the "pre-integration-test" and
> "post-integration-test" phases are designed to allow setting up and tearing
> down the integration test environment, and, despite their names, the
> post-integration-test phase is *not* a finally block. So you need to be
> careful when binding plugins to the integration-test phase that such
> plugins *never* fail the build...
>
> At this point we have the Maven Failsafe Plugin enter the fray... this has
> two goals: failsafe:integration-test and failsafe:verify which, by default,
> bind to the integration-test and verify phases respectively.
>
> The `failsafe:integration-test` goal will run integration tests, but never
> fails the build.
> The `failsafe:verify` goal will check the results of
> `failsafe:integration-test` and fail the build if the tests fail.
>
> Thus you should be able to add failsafe to the mix by just adding
>
> <plugin>
> <artifactId>maven-failsafe-plugin</artifactId>
> <executions>
> <execution>
> <goals>
> <goal>integration-test</goal>
> <goal>verify</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
>
> Now since failsafe is running after the `package` phase, it *should* be
> using the project artifact in place of target/classes *when* executed after
> the `package` phase... as all plugins should do... *but* I suspect there is
> a bug in failsafe that causes it to explicitly add target/classes.
>
> TL;DR it should be Maven Failsafe Plugin that gives this feature *but* I
> suspect there is a bug in that plugin that is causing it to use the
> directory in place of the .jar.
>
> Kristian, can you confirm my summary?
>
> -Stephen
>
>
> On 30 April 2013 12:11, Stephen Colebourne <sc...@joda.org> wrote:
>
> > I would like to be able to achieve the following using two command
> > line invocations:
> > - build and install jar files using "mvn install"
> > - run tests again, but against the installed jar files
> >
> > The rationale is that the first mvn run will only run "unit" tests
> > (using test groups in TestNG), whereas the second mvn run would run
> > all tests, including "slow" and "database" tests. In reality, both
> > would be run from a CI server rather than a developer desktop.
> >
> > Clearly, the first mvn run is easy (I have that working). But I cannot
> > see a way to run a mvn command that executes the tests against the
> > installed jar files.
> >
> > The project is a multi-module project. Moving tests into a separate
> > "testing only" project is not an acceptable approach. Running the
> > slow/database tests as part of a single mvn run is not an acceptable
> > approach.
> >
> > thanks for any thoughts or hyperlinks.
> > Stephen
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>

Re: Testing jar files instead of class files

Posted by Stephen Connolly <st...@gmail.com>.
Well just to put this into context.

What you actually want to do is run your second set of tests after the
'package' phase and before the 'install' phase. There is only the 'deploy'
phase after the 'install' phase so there would be no scope to run tests
after the 'install' phase.

If you look at the lifecycle, you will see the handy:

'integration-test'
and
'verify'

phases.

Now use of these phases is slightly different. Because you actually *never*
want to type "mvn integration-test" and any time you think you do, you
should actually type "mvn verify" in its place.

The reason for this is that the "pre-integration-test" and
"post-integration-test" phases are designed to allow setting up and tearing
down the integration test environment, and, despite their names, the
post-integration-test phase is *not* a finally block. So you need to be
careful when binding plugins to the integration-test phase that such
plugins *never* fail the build...

At this point we have the Maven Failsafe Plugin enter the fray... this has
two goals: failsafe:integration-test and failsafe:verify which, by default,
bind to the integration-test and verify phases respectively.

The `failsafe:integration-test` goal will run integration tests, but never
fails the build.
The `failsafe:verify` goal will check the results of
`failsafe:integration-test` and fail the build if the tests fail.

Thus you should be able to add failsafe to the mix by just adding

<plugin>
<artifactId>maven-failsafe-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>

Now since failsafe is running after the `package` phase, it *should* be
using the project artifact in place of target/classes *when* executed after
the `package` phase... as all plugins should do... *but* I suspect there is
a bug in failsafe that causes it to explicitly add target/classes.

TL;DR it should be Maven Failsafe Plugin that gives this feature *but* I
suspect there is a bug in that plugin that is causing it to use the
directory in place of the .jar.

Kristian, can you confirm my summary?

-Stephen


On 30 April 2013 12:11, Stephen Colebourne <sc...@joda.org> wrote:

> I would like to be able to achieve the following using two command
> line invocations:
> - build and install jar files using "mvn install"
> - run tests again, but against the installed jar files
>
> The rationale is that the first mvn run will only run "unit" tests
> (using test groups in TestNG), whereas the second mvn run would run
> all tests, including "slow" and "database" tests. In reality, both
> would be run from a CI server rather than a developer desktop.
>
> Clearly, the first mvn run is easy (I have that working). But I cannot
> see a way to run a mvn command that executes the tests against the
> installed jar files.
>
> The project is a multi-module project. Moving tests into a separate
> "testing only" project is not an acceptable approach. Running the
> slow/database tests as part of a single mvn run is not an acceptable
> approach.
>
> thanks for any thoughts or hyperlinks.
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>