Re: Running integration tests twice against different webapp configurations

[Ellis, Scott]

If you try to call the start goal twice in the pre-integration-test phase, the 
second one fails with the IllegalStateException "ShutdownMonitor already 
started." It must be run-forked in order to start properly.
Thanks,
Scott

-Original Message-
From: Paul Hammant [mailto:p...@hammant.org] 
Sent: Saturday, October 13, 2018 9:00 AM
To: Maven Users List 
Subject: [SUSPICIOUS] Re: [SUSPICIOUS] Re: Running integration tests twice 
against different webapp configurations

You're explicitly calling stop() on both Jetty instances ... (pass or fail) and 
not just letting it fall through to the Shutdown hook which is static ?


On Sat, Oct 13, 2018 at 1:31 AM Ellis, Scott 
wrote:

> Thank you Thomas! The parallel solution worked  or me. And thanks for 
> the other replies too.
>
> For the record, the second jetty instance must use the run-forked 
> goal, because  the ShutdownMonitor thread in jetty is declared static. 
> A design flaw in my opinion. Trying to run a second jetty instance in 
> the same vm fails with error "ShutdownMonitor already started,"  even 
> with a different key and port.
>
> Thanks,
> Scott
>
> -Original Message-
> From: Thomas Broyer [mailto:t.bro...@gmail.com]
> Sent: Friday, October 12, 2018 2:34 AM
> To: Maven Users List 
> Subject: [SUSPICIOUS] Re: Running integration tests twice against 
> different webapp configurations
>
> Alternatively, if possible, you could possibly run the app with both 
> configurations in parallel (two executions of jetty-maven-plugin in 
> pre-integration-test and post-integration-test phase, using different 
> ports), and run you tests twice, for each app / port (two executions 
> of failsafe at integration-test phase)
>
> On Fri, Oct 12, 2018 at 8:44 AM Anders Hammar  wrote:
>
> > I'd say you need two modules; one for each IT setup. Each module is 
> > a Maven project and will then run the integration tests. The actual 
> > integration test code could then be in a third module and you 
> > declare a dependency on that artifact.
> >
> > /Anders
> >
> > On Thu, Oct 11, 2018 at 11:21 PM Ellis, Scott 
> >  > >
> > wrote:
> >
> > > Hi,
> > >
> > > I have a project that builds a webapp and runs integration tests 
> > > against it using the failsafe plugin and the jetty-maven-plugin.
> > >
> > > That is, I use the jetty-maven-plugin to start jetty in the 
> > > pre-integration-test phase, run the tests, then shut jetty down in 
> > > the post-integration-test phase.
> > >
> > > Now, my web app can have an entirely different configuration in 
> > > addition to the existing one, so I need to start jetty with a new 
> > > config and run a new suite of tests, while maintaining all the
> existing functionality.
> > >
> > > So what I really want to do it run these phases twice:
> > >
> > > pre-integration-test
> > > integration-test
> > > post-integration-test
> > >
> > > First I want to run them with the my webapp configured the old 
> > > way, and then run the same phases again with my webapp configured 
> > > the new
> way.
> > >
> > > Any advice on how to do this? The configurations can be set with 
> > > system properties. The problem is how to run those phases twice in
> that order.
> > >
> > > Thanks for any insight you can offer, Scott
> > >
> >
>

Re: [SUSPICIOUS] Re: Running integration tests twice against different webapp configurations

[Paul Hammant]

You're explicitly calling stop() on both Jetty instances ... (pass or fail)
and not just letting it fall through to the Shutdown hook which is static ?


On Sat, Oct 13, 2018 at 1:31 AM Ellis, Scott 
wrote:

> Thank you Thomas! The parallel solution worked  or me. And thanks for the
> other replies too.
>
> For the record, the second jetty instance must use the run-forked goal,
> because  the ShutdownMonitor thread in jetty is declared static. A design
> flaw in my opinion. Trying to run a second jetty instance in the same vm
> fails with error "ShutdownMonitor already started,"  even with a different
> key and port.
>
> Thanks,
> Scott
>
> -Original Message-
> From: Thomas Broyer [mailto:t.bro...@gmail.com]
> Sent: Friday, October 12, 2018 2:34 AM
> To: Maven Users List 
> Subject: [SUSPICIOUS] Re: Running integration tests twice against
> different webapp configurations
>
> Alternatively, if possible, you could possibly run the app with both
> configurations in parallel (two executions of jetty-maven-plugin in
> pre-integration-test and post-integration-test phase, using different
> ports), and run you tests twice, for each app / port (two executions of
> failsafe at integration-test phase)
>
> On Fri, Oct 12, 2018 at 8:44 AM Anders Hammar  wrote:
>
> > I'd say you need two modules; one for each IT setup. Each module is a
> > Maven project and will then run the integration tests. The actual
> > integration test code could then be in a third module and you declare
> > a dependency on that artifact.
> >
> > /Anders
> >
> > On Thu, Oct 11, 2018 at 11:21 PM Ellis, Scott
> >  > >
> > wrote:
> >
> > > Hi,
> > >
> > > I have a project that builds a webapp and runs integration tests
> > > against it using the failsafe plugin and the jetty-maven-plugin.
> > >
> > > That is, I use the jetty-maven-plugin to start jetty in the
> > > pre-integration-test phase, run the tests, then shut jetty down in
> > > the post-integration-test phase.
> > >
> > > Now, my web app can have an entirely different configuration in
> > > addition to the existing one, so I need to start jetty with a new
> > > config and run a new suite of tests, while maintaining all the
> existing functionality.
> > >
> > > So what I really want to do it run these phases twice:
> > >
> > > pre-integration-test
> > > integration-test
> > > post-integration-test
> > >
> > > First I want to run them with the my webapp configured the old way,
> > > and then run the same phases again with my webapp configured the new
> way.
> > >
> > > Any advice on how to do this? The configurations can be set with
> > > system properties. The problem is how to run those phases twice in
> that order.
> > >
> > > Thanks for any insight you can offer, Scott
> > >
> >
>

RE: [SUSPICIOUS] Re: Running integration tests twice against different webapp configurations

[Ellis, Scott]

Thank you Thomas! The parallel solution worked  or me. And thanks for the other 
replies too.

For the record, the second jetty instance must use the run-forked goal, because 
 the ShutdownMonitor thread in jetty is declared static. A design flaw in my 
opinion. Trying to run a second jetty instance in the same vm fails with error 
"ShutdownMonitor already started,"  even with a different key and port.

Thanks,
Scott

-Original Message-
From: Thomas Broyer [mailto:t.bro...@gmail.com] 
Sent: Friday, October 12, 2018 2:34 AM
To: Maven Users List 
Subject: [SUSPICIOUS] Re: Running integration tests twice against different 
webapp configurations

Alternatively, if possible, you could possibly run the app with both 
configurations in parallel (two executions of jetty-maven-plugin in 
pre-integration-test and post-integration-test phase, using different ports), 
and run you tests twice, for each app / port (two executions of failsafe at 
integration-test phase)

On Fri, Oct 12, 2018 at 8:44 AM Anders Hammar  wrote:

> I'd say you need two modules; one for each IT setup. Each module is a 
> Maven project and will then run the integration tests. The actual 
> integration test code could then be in a third module and you declare 
> a dependency on that artifact.
>
> /Anders
>
> On Thu, Oct 11, 2018 at 11:21 PM Ellis, Scott 
>  >
> wrote:
>
> > Hi,
> >
> > I have a project that builds a webapp and runs integration tests 
> > against it using the failsafe plugin and the jetty-maven-plugin.
> >
> > That is, I use the jetty-maven-plugin to start jetty in the 
> > pre-integration-test phase, run the tests, then shut jetty down in 
> > the post-integration-test phase.
> >
> > Now, my web app can have an entirely different configuration in 
> > addition to the existing one, so I need to start jetty with a new 
> > config and run a new suite of tests, while maintaining all the existing 
> > functionality.
> >
> > So what I really want to do it run these phases twice:
> >
> > pre-integration-test
> > integration-test
> > post-integration-test
> >
> > First I want to run them with the my webapp configured the old way, 
> > and then run the same phases again with my webapp configured the new way.
> >
> > Any advice on how to do this? The configurations can be set with 
> > system properties. The problem is how to run those phases twice in that 
> > order.
> >
> > Thanks for any insight you can offer, Scott
> >
>

Re: Running integration tests twice against different webapp configurations

[Paul Hammant]

There's Cuppa which is super cool and allows to control such things to a
very fine level.

https://github.com/cuppa-framework/cuppa/

It is not clear that Cuppa has multi-year life though. I wish it did.

On Thu, Oct 11, 2018 at 10:21 PM Ellis, Scott 
wrote:

> Hi,
>
> I have a project that builds a webapp and runs integration tests against
> it using the failsafe plugin and the jetty-maven-plugin.
>
> That is, I use the jetty-maven-plugin to start jetty in the
> pre-integration-test phase, run the tests, then shut jetty down in the
> post-integration-test phase.
>
> Now, my web app can have an entirely different configuration in addition
> to the existing one, so I need to start jetty with a new config and run a
> new suite of tests, while maintaining all the existing functionality.
>
> So what I really want to do it run these phases twice:
>
> pre-integration-test
> integration-test
> post-integration-test
>
> First I want to run them with the my webapp configured the old way, and
> then run the same phases again with my webapp configured the new way.
>
> Any advice on how to do this? The configurations can be set with system
> properties. The problem is how to run those phases twice in that order.
>
> Thanks for any insight you can offer,
> Scott
>

Re: Running integration tests twice against different webapp configurations

[Thomas Broyer]

Alternatively, if possible, you could possibly run the app with both
configurations in parallel (two executions of jetty-maven-plugin in
pre-integration-test and post-integration-test phase, using different
ports), and run you tests twice, for each app / port (two executions of
failsafe at integration-test phase)

On Fri, Oct 12, 2018 at 8:44 AM Anders Hammar  wrote:

> I'd say you need two modules; one for each IT setup. Each module is a Maven
> project and will then run the integration tests. The actual integration
> test code could then be in a third module and you declare a dependency on
> that artifact.
>
> /Anders
>
> On Thu, Oct 11, 2018 at 11:21 PM Ellis, Scott  >
> wrote:
>
> > Hi,
> >
> > I have a project that builds a webapp and runs integration tests against
> > it using the failsafe plugin and the jetty-maven-plugin.
> >
> > That is, I use the jetty-maven-plugin to start jetty in the
> > pre-integration-test phase, run the tests, then shut jetty down in the
> > post-integration-test phase.
> >
> > Now, my web app can have an entirely different configuration in addition
> > to the existing one, so I need to start jetty with a new config and run a
> > new suite of tests, while maintaining all the existing functionality.
> >
> > So what I really want to do it run these phases twice:
> >
> > pre-integration-test
> > integration-test
> > post-integration-test
> >
> > First I want to run them with the my webapp configured the old way, and
> > then run the same phases again with my webapp configured the new way.
> >
> > Any advice on how to do this? The configurations can be set with system
> > properties. The problem is how to run those phases twice in that order.
> >
> > Thanks for any insight you can offer,
> > Scott
> >
>

Re: Running integration tests twice against different webapp configurations

[Anders Hammar]

I'd say you need two modules; one for each IT setup. Each module is a Maven
project and will then run the integration tests. The actual integration
test code could then be in a third module and you declare a dependency on
that artifact.

/Anders

On Thu, Oct 11, 2018 at 11:21 PM Ellis, Scott 
wrote:

> Hi,
>
> I have a project that builds a webapp and runs integration tests against
> it using the failsafe plugin and the jetty-maven-plugin.
>
> That is, I use the jetty-maven-plugin to start jetty in the
> pre-integration-test phase, run the tests, then shut jetty down in the
> post-integration-test phase.
>
> Now, my web app can have an entirely different configuration in addition
> to the existing one, so I need to start jetty with a new config and run a
> new suite of tests, while maintaining all the existing functionality.
>
> So what I really want to do it run these phases twice:
>
> pre-integration-test
> integration-test
> post-integration-test
>
> First I want to run them with the my webapp configured the old way, and
> then run the same phases again with my webapp configured the new way.
>
> Any advice on how to do this? The configurations can be set with system
> properties. The problem is how to run those phases twice in that order.
>
> Thanks for any insight you can offer,
> Scott
>

Re: Running integration tests against a signed jar

[Gary Gregory]

Hm, so I have two choices:

- Change the POM so that the failsafe plugin runs in the test phase, which
happens before the jar signing (that works BTW).
- Change the code to repackage the IT tests and make public all that the IT
tests need (I've not done that but I'll see what breaks)

Thank you all,
Gary


On Tue, May 30, 2017 at 12:15 PM, Bernd Eckenfels 
wrote:

> I think the maven way is not much concerned with package structure,
> however why not have a IT package? Do you have much need for package access
> in your ITs?
>
> For Unit tests sharing the packages can be helpful, but for IT I would
> expect it does not only need to be collocated, but it actually is better to
> have the public view. (Some hooks might be required to open up state for
> initilisation and verification, not sure. In the cases I have seen public
> interface (or access to external systems like file or database) was enough.
>
> Are those webstart client chars or do you use signed protection domains on
> the server or is this only signing for protecting the archives?
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: Martin Gainty 
> Sent: Tuesday, May 30, 2017 7:08:43 PM
> To: Maven Users List
> Subject: Re: Running integration tests against a signed jar
>
>
>
> 
> From: Gary Gregory 
> Sent: Monday, May 29, 2017 5:01 PM
> To: Maven Users List
> Subject: Running integration tests against a signed jar
>
> Hi All:
>
> I have a POM that builds a signed jar, so far so good. Unit tests run, no
> problem.
>
> When integration tests run through fail-safe, the build fails all ITs with:
>
> java.lang.ExceptionInInitializerError
> Caused by: java.lang.SecurityException: class "com.example.MyClass"'s
> signer information does not match signer information of other classes in
> the same package
>
> MG>you are running a jar with a bad signature
> MG>you are running a jar with no signature
> MG>to confirm
> MG>for every jar in your runtime classpath
> MG>BEGIN:
> MG>for each jar expand next runtime jar
> MG>edit /META-INF/MANIFEST.MF of current jar
> MG>the signature would look something like
> MG>net/sf/jasperreports/engine/util/xml/JaxenXPathExecuterFactory.class
> SHA-256-Digest: q3B5wW+hLX/+lP2+L0/6wRVXRHq1mISBo1dkixT6Vxc=
> MG>save the first signature to outside file buffer
> MG>compare  entryFromMANIFEST.MF to first-signature
> MG>if not equal or non-existent resign current jar with algorithm from
> first signed jar
> MG>goto BEGIN
>
> As I understand it, failsafe runs the classes in test-classes against the
> built JAR, and since my ITs are in the same package as the code tested, I
> get the signing error above.
>
> What is the Maven-way to get this to work?
>
> Thank you,
> Gary
>
> --
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
> JUnit in Action, Second Edition: Petar Tahchiev, Felipe Leme, Vincent
> Massol, Gary Gregory: 9781935182023: Amazon.com: Books<
> https://www.amazon.com/gp/product/1935182021/ref=as_
> li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=
> 1935182021&linkCode=as2&tag=garygregory-20&linkId=
> 31ecd1f6b6d1eaf8886ac902a24de418%22>
> www.amazon.com<http://www.amazon.com>
> JUnit in Action, Second Edition [Petar Tahchiev, Felipe Leme, Vincent
> Massol, Gary Gregory] on Amazon.com. *FREE* shipping on qualifying offers.
> When JUnit was first introduced a decade ago by Kent Beck and Erich Gamma,
> the Agile movement was in its infancy
>
>
>
>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> Spring Batch in Action: Arnaud Cogoluegnes, Thierry Templier, Gary
> Gregory, Olivier Bazoud: 9781935182955: Ama

Re: Running integration tests against a signed jar

[Bernd Eckenfels]

I think the maven way is not much concerned with package structure, however why 
not have a IT package? Do you have much need for package access in your ITs?

For Unit tests sharing the packages can be helpful, but for IT I would expect 
it does not only need to be collocated, but it actually is better to have the 
public view. (Some hooks might be required to open up state for initilisation 
and verification, not sure. In the cases I have seen public interface (or 
access to external systems like file or database) was enough.

Are those webstart client chars or do you use signed protection domains on the 
server or is this only signing for protecting the archives?

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Martin Gainty 
Sent: Tuesday, May 30, 2017 7:08:43 PM
To: Maven Users List
Subject: Re: Running integration tests against a signed jar




From: Gary Gregory 
Sent: Monday, May 29, 2017 5:01 PM
To: Maven Users List
Subject: Running integration tests against a signed jar

Hi All:

I have a POM that builds a signed jar, so far so good. Unit tests run, no
problem.

When integration tests run through fail-safe, the build fails all ITs with:

java.lang.ExceptionInInitializerError
Caused by: java.lang.SecurityException: class "com.example.MyClass"'s
signer information does not match signer information of other classes in
the same package

MG>you are running a jar with a bad signature
MG>you are running a jar with no signature
MG>to confirm
MG>for every jar in your runtime classpath
MG>BEGIN:
MG>for each jar expand next runtime jar
MG>edit /META-INF/MANIFEST.MF of current jar
MG>the signature would look something like
MG>net/sf/jasperreports/engine/util/xml/JaxenXPathExecuterFactory.class 
SHA-256-Digest: q3B5wW+hLX/+lP2+L0/6wRVXRHq1mISBo1dkixT6Vxc=
MG>save the first signature to outside file buffer
MG>compare  entryFromMANIFEST.MF to first-signature
MG>if not equal or non-existent resign current jar with algorithm from first 
signed jar
MG>goto BEGIN

As I understand it, failsafe runs the classes in test-classes against the
built JAR, and since my ITs are in the same package as the code tested, I
get the signing error above.

What is the Maven-way to get this to work?

Thank you,
Gary

--
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
JUnit in Action, Second Edition: Petar Tahchiev, Felipe Leme, Vincent Massol, 
Gary Gregory: 9781935182023: Amazon.com: 
Books<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
www.amazon.com<http://www.amazon.com>
JUnit in Action, Second Edition [Petar Tahchiev, Felipe Leme, Vincent Massol, 
Gary Gregory] on Amazon.com. *FREE* shipping on qualifying offers.
When JUnit was first introduced a decade ago by Kent Beck and Erich Gamma, the 
Agile movement was in its infancy




<http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
Spring Batch in Action: Arnaud Cogoluegnes, Thierry Templier, Gary Gregory, 
Olivier Bazoud: 9781935182955: Amazon.com: 
Books<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
www.amazon.com<http://www.amazon.com>
Spring Batch in Action [Arnaud Cogoluegnes, Thierry Templier, Gary Gregory, 
Olivier Bazoud] on Amazon.com. *FREE* shipping on qualifying offers.
Summary Spring Batch in Action is an in-depth guide to writing batch 
applications using Spring Batch. Written for developers who have basic 
knowledge of Java and the Spring lightweight container



<http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
[https://s0.wp.com/i/blank.jpg]<http://garygregory.wordpress.com/>

Gary Gregory<http://garygregory.wordpress.com/>
garygregory.wordpress.com
Software construction, the web, and other techs

Re: Running integration tests against a signed jar

[Martin Gainty]

From: Gary Gregory 
Sent: Monday, May 29, 2017 5:01 PM
To: Maven Users List
Subject: Running integration tests against a signed jar

Hi All:

I have a POM that builds a signed jar, so far so good. Unit tests run, no
problem.

When integration tests run through fail-safe, the build fails all ITs with:

java.lang.ExceptionInInitializerError
Caused by: java.lang.SecurityException: class "com.example.MyClass"'s
signer information does not match signer information of other classes in
the same package

MG>you are running a jar with a bad signature
MG>you are running a jar with no signature
MG>to confirm
MG>for every jar in your runtime classpath
MG>BEGIN:
MG>for each jar expand next runtime jar
MG>edit /META-INF/MANIFEST.MF of current jar
MG>the signature would look something like
MG>net/sf/jasperreports/engine/util/xml/JaxenXPathExecuterFactory.class 
SHA-256-Digest: q3B5wW+hLX/+lP2+L0/6wRVXRHq1mISBo1dkixT6Vxc=
MG>save the first signature to outside file buffer
MG>compare  entryFromMANIFEST.MF to first-signature
MG>if not equal or non-existent resign current jar with algorithm from first 
signed jar
MG>goto BEGIN

As I understand it, failsafe runs the classes in test-classes against the
built JAR, and since my ITs are in the same package as the code tested, I
get the signing error above.

What is the Maven-way to get this to work?

Thank you,
Gary

--
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition

JUnit in Action, Second Edition: Petar Tahchiev, Felipe Leme, Vincent Massol, 
Gary Gregory: 9781935182023: Amazon.com: 
Books
www.amazon.com
JUnit in Action, Second Edition [Petar Tahchiev, Felipe Leme, Vincent Massol, 
Gary Gregory] on Amazon.com. *FREE* shipping on qualifying offers.
When JUnit was first introduced a decade ago by Kent Beck and Erich Gamma, the 
Agile movement was in its infancy





Spring Batch in Action

Spring Batch in Action: Arnaud Cogoluegnes, Thierry Templier, Gary Gregory, 
Olivier Bazoud: 9781935182955: Amazon.com: 
Books
www.amazon.com
Spring Batch in Action [Arnaud Cogoluegnes, Thierry Templier, Gary Gregory, 
Olivier Bazoud] on Amazon.com. *FREE* shipping on qualifying offers.
Summary Spring Batch in Action is an in-depth guide to writing batch 
applications using Spring Batch. Written for developers who have basic 
knowledge of Java and the Spring lightweight container




Blog: http://garygregory.wordpress.com
[https://s0.wp.com/i/blank.jpg]

Gary Gregory
garygregory.wordpress.com
Software construction, the web, and other techs

Re: Running integration tests

[Karl Heinz Marbaise]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Running integration tests

[Stephen Connolly]

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  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-unsubscr...@maven.apache.org
> > 
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > > 
> > >
> > >
> >
> > --
> > Sent from my phone
> >
>

Re: Running integration tests

[Anders Hammar]

>
> 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-unsubscr...@maven.apache.org
> 
> > For additional commands, e-mail: users-h...@maven.apache.org
> > 
> >
> >
>
> --
> Sent from my phone
>

Re: Running integration tests

[Stephen Connolly]

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 
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-unsubscr...@maven.apache.org 
> For additional commands, e-mail: users-h...@maven.apache.org
> 
>
>

-- 
Sent from my phone

Re: Running integration tests

[Manfred Moser]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Running integration tests

[Robert Mark Bram]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Running integration tests

[Stephen Connolly]

On 6 October 2014 10:31, 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?
>

> 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

Re: running integration tests with maven

[Glenn Brown]

http://docs.codehaus.org/plugins/servlet/mobile#content/view/63286
 On May 15, 2014 10:14 PM, "Brendan Miller"  wrote:

> I currently have some testng integration tests in a maven project. This is
> causing problems because the tests get picked up and run during the test
> phase, rather than the integration-test phase.
>
> How do I cause tests to be run in the integration test phase rather than
> test? All of my tests in this particular module should be run during
> integration-test.
>
> I don't really see anything in my pom.xml that specifies phase. This is the
> only test specific thing I'm seeing:
>
> 
> org.testng
> testng
> ${testng.version}
> compile
> 
>
> That by itself seems to be running the  tests in my class BlahTest.java.
> I'm guessing it automatically picks up anything matching Test.java?
>
> Thanks,
> Brendan
>

Re: running integration tests with maven

[Anders Hammar]

You need to add/bind the maven-failsafe-plugin to your build:
http://maven.apache.org/surefire/maven-failsafe-plugin/usage.html

You also need to adapt the naming of your test files:
http://maven.apache.org/surefire/maven-failsafe-plugin/examples/inclusion-exclusion.html

/Anders


On Thu, May 8, 2014 at 2:45 AM, Brendan Miller wrote:

> I currently have some testng integration tests in a maven project. This is
> causing problems because the tests get picked up and run during the test
> phase, rather than the integration-test phase.
>
> How do I cause tests to be run in the integration test phase rather than
> test? All of my tests in this particular module should be run during
> integration-test.
>
> I don't really see anything in my pom.xml that specifies phase. This is the
> only test specific thing I'm seeing:
>
> 
> org.testng
> testng
> ${testng.version}
> compile
> 
>
> That by itself seems to be running the  tests in my class BlahTest.java.
> I'm guessing it automatically picks up anything matching Test.java?
>
> Thanks,
> Brendan
>

RE: Running integration tests

[David Jackman]

It looks like Cargo is a wrapper for J2EE containers.  I don't see how
this would help in this specific situation, since my project is a client
calling the server and the server is not a J2EE application.
The point of the tests is to ensure that the assumptions I made about
the server communication protocol when creating the mock objects for the
unit tests is actually valid.  The only way to really do this is to have
the actual server set up and actually talk to it.  Configuring the
server involves installing the server, manipulating some configuration
files, loading the server with content, and starting & restarting the
server.  This could potentially be automated (though the server doesn't
really support automation for everything at this time), but even then it
wouldn't be something we'd want to run with every build.

I'd rather not make a separate project for this, since I'd like them
more closely associated with the project it's testing, but could do it
as a last resort.


-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 13, 2005 10:56 AM
To: 'Maven Users List'
Subject: RE: Running integration tests



> -Original Message-
> From: David Jackman [mailto:[EMAIL PROTECTED]
> Sent: vendredi 13 mai 2005 18:32
> To: Maven Users List
> Subject: Running integration tests
> 
> For one of my projects, I need to add some integration tests that are 
> separate from the unit tests.  The unit tests work as they 
> should--they are fully automated and run with every build.  The 
> integration tests are different in that they can't be fully automated 
> since they depend on some external resources (in this case a 
> specifically configured server) being available.

Why can't this be automated? Maybe Cargo (http://cargo.codehaus.org)
could help?

http://tinyurl.com/8djb
http://tinyurl.com/dnll2
http://tinyurl.com/btmwa

>  However, when these resources are in place I would like to be able to

> use Maven to run the tests.  I didn't see a plugin that directly 
> addresses this situation, but did notice the 
> "integrationUnitTestSourceDirectory" element of the POM that has been 
> documented as deprecated.  Is anyone out there doing this sort of
thing?
> Is there a best practice I can follow for the fewest headaches?

Maybe the Cargo Maven plugin?
 
> Here was my planned approach:
> 1. Create an "integrationtest" directory tree in src that is a sibling

> to the unit tests in "test".  The integrationtest directory will have 
> a java subdir for the source code, a resources directory for 
> non-compiled files that need to be in the classpath, and a data 
> directory that contains the files and instructions necessary for 
> setting up the external resources.

An idea: Why don't you create a separate subproject to run your
integration tests that you would put in src/test?

> 2. Create "integrationtest:xxx" goals in the project's maven.xml that 
> correspond to the test plugin goals the set the test plugin properties

> to point to the integrationtest directory then run the corresponding 
> test goal.
> 
> Thanks,
> ..David..

-Vincent





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


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

RE: Running integration tests

[Vincent Massol]

> -Original Message-
> From: Thomas Van de Velde [mailto:[EMAIL PROTECTED]
> Sent: vendredi 13 mai 2005 20:01
> To: Maven Users List
> Subject: Re: Running integration tests
> 
> Vincent,
> 
> Any plans on building Cargo support for WAS?

Definitely... as soon as someone is interested in contributing and
maintaining the implementation for WAS. It's quite easy to do actually.

I'll be happy to support anyone who wants to help on that.

Thanks
-Vincent

> On 5/13/05, Vincent Massol <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > > -Original Message-
> > > From: David Jackman [mailto:[EMAIL PROTECTED]
> > > Sent: vendredi 13 mai 2005 18:32
> > > To: Maven Users List
> > > Subject: Running integration tests
> > >
> > > For one of my projects, I need to add some integration tests that are
> > > separate from the unit tests. The unit tests work as they should--they
> > > are fully automated and run with every build. The integration tests
> are
> > > different in that they can't be fully automated since they depend on
> > > some external resources (in this case a specifically configured
> server)
> > > being available.
> >
> > Why can't this be automated? Maybe Cargo (http://cargo.codehaus.org)
> could
> > help?
> >
> > http://tinyurl.com/8djb
> > http://tinyurl.com/dnll2
> > http://tinyurl.com/btmwa
> >
> > > However, when these resources are in place I would
> > > like to be able to use Maven to run the tests. I didn't see a plugin
> > > that directly addresses this situation, but did notice the
> > > "integrationUnitTestSourceDirectory" element of the POM that has been
> > > documented as deprecated. Is anyone out there doing this sort of
> thing?
> > > Is there a best practice I can follow for the fewest headaches?
> >
> > Maybe the Cargo Maven plugin?
> >
> > > Here was my planned approach:
> > > 1. Create an "integrationtest" directory tree in src that is a sibling
> > > to the unit tests in "test". The integrationtest directory will have a
> > > java subdir for the source code, a resources directory for non-
> compiled
> > > files that need to be in the classpath, and a data directory that
> > > contains the files and instructions necessary for setting up the
> > > external resources.
> >
> > An idea: Why don't you create a separate subproject to run your
> > integration
> > tests that you would put in src/test?
> >
> > > 2. Create "integrationtest:xxx" goals in the project's maven.xml that
> > > correspond to the test plugin goals the set the test plugin properties
> > > to point to the integrationtest directory then run the corresponding
> > > test goal.
> > >
> > > Thanks,
> > > ..David..
> >
> > -Vincent
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >




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

RE: Running integration tests

[Vincent Massol]

> -Original Message-
> From: Thomas Van de Velde [mailto:[EMAIL PROTECTED]
> Sent: vendredi 13 mai 2005 20:01
> To: Maven Users List
> Subject: Re: Running integration tests
> 
> Vincent,
> 
> Any plans on building Cargo support for WAS?

Definitely... as soon as someone is interested in contributing and
maintaining the implementation for WAS. It's quite easy to do actually.

I'll be happy to support anyone who wants to help on that.

Thanks
-Vincent

> On 5/13/05, Vincent Massol <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > > -Original Message-
> > > From: David Jackman [mailto:[EMAIL PROTECTED]
> > > Sent: vendredi 13 mai 2005 18:32
> > > To: Maven Users List
> > > Subject: Running integration tests
> > >
> > > For one of my projects, I need to add some integration tests that are
> > > separate from the unit tests. The unit tests work as they should--they
> > > are fully automated and run with every build. The integration tests
> are
> > > different in that they can't be fully automated since they depend on
> > > some external resources (in this case a specifically configured
> server)
> > > being available.
> >
> > Why can't this be automated? Maybe Cargo (http://cargo.codehaus.org)
> could
> > help?
> >
> > http://tinyurl.com/8djb
> > http://tinyurl.com/dnll2
> > http://tinyurl.com/btmwa
> >
> > > However, when these resources are in place I would
> > > like to be able to use Maven to run the tests. I didn't see a plugin
> > > that directly addresses this situation, but did notice the
> > > "integrationUnitTestSourceDirectory" element of the POM that has been
> > > documented as deprecated. Is anyone out there doing this sort of
> thing?
> > > Is there a best practice I can follow for the fewest headaches?
> >
> > Maybe the Cargo Maven plugin?
> >
> > > Here was my planned approach:
> > > 1. Create an "integrationtest" directory tree in src that is a sibling
> > > to the unit tests in "test". The integrationtest directory will have a
> > > java subdir for the source code, a resources directory for non-
> compiled
> > > files that need to be in the classpath, and a data directory that
> > > contains the files and instructions necessary for setting up the
> > > external resources.
> >
> > An idea: Why don't you create a separate subproject to run your
> > integration
> > tests that you would put in src/test?
> >
> > > 2. Create "integrationtest:xxx" goals in the project's maven.xml that
> > > correspond to the test plugin goals the set the test plugin properties
> > > to point to the integrationtest directory then run the corresponding
> > > test goal.
> > >
> > > Thanks,
> > > ..David..
> >
> > -Vincent
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >




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

Re: Running integration tests

[Thomas Van de Velde]

Vincent,

Any plans on building Cargo support for WAS?

Cheers,
Thomas

On 5/13/05, Vincent Massol <[EMAIL PROTECTED]> wrote:
> 
> 
> 
> > -Original Message-
> > From: David Jackman [mailto:[EMAIL PROTECTED]
> > Sent: vendredi 13 mai 2005 18:32
> > To: Maven Users List
> > Subject: Running integration tests
> >
> > For one of my projects, I need to add some integration tests that are
> > separate from the unit tests. The unit tests work as they should--they
> > are fully automated and run with every build. The integration tests are
> > different in that they can't be fully automated since they depend on
> > some external resources (in this case a specifically configured server)
> > being available.
> 
> Why can't this be automated? Maybe Cargo (http://cargo.codehaus.org) could
> help?
> 
> http://tinyurl.com/8djb
> http://tinyurl.com/dnll2
> http://tinyurl.com/btmwa
> 
> > However, when these resources are in place I would
> > like to be able to use Maven to run the tests. I didn't see a plugin
> > that directly addresses this situation, but did notice the
> > "integrationUnitTestSourceDirectory" element of the POM that has been
> > documented as deprecated. Is anyone out there doing this sort of thing?
> > Is there a best practice I can follow for the fewest headaches?
> 
> Maybe the Cargo Maven plugin?
> 
> > Here was my planned approach:
> > 1. Create an "integrationtest" directory tree in src that is a sibling
> > to the unit tests in "test". The integrationtest directory will have a
> > java subdir for the source code, a resources directory for non-compiled
> > files that need to be in the classpath, and a data directory that
> > contains the files and instructions necessary for setting up the
> > external resources.
> 
> An idea: Why don't you create a separate subproject to run your 
> integration
> tests that you would put in src/test?
> 
> > 2. Create "integrationtest:xxx" goals in the project's maven.xml that
> > correspond to the test plugin goals the set the test plugin properties
> > to point to the integrationtest directory then run the corresponding
> > test goal.
> >
> > Thanks,
> > ..David..
> 
> -Vincent
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

RE: Running integration tests

[Vincent Massol]

> -Original Message-
> From: David Jackman [mailto:[EMAIL PROTECTED]
> Sent: vendredi 13 mai 2005 18:32
> To: Maven Users List
> Subject: Running integration tests
> 
> For one of my projects, I need to add some integration tests that are
> separate from the unit tests.  The unit tests work as they should--they
> are fully automated and run with every build.  The integration tests are
> different in that they can't be fully automated since they depend on
> some external resources (in this case a specifically configured server)
> being available.

Why can't this be automated? Maybe Cargo (http://cargo.codehaus.org) could
help?

http://tinyurl.com/8djb
http://tinyurl.com/dnll2
http://tinyurl.com/btmwa

>  However, when these resources are in place I would
> like to be able to use Maven to run the tests.  I didn't see a plugin
> that directly addresses this situation, but did notice the
> "integrationUnitTestSourceDirectory" element of the POM that has been
> documented as deprecated.  Is anyone out there doing this sort of thing?
> Is there a best practice I can follow for the fewest headaches?

Maybe the Cargo Maven plugin?
 
> Here was my planned approach:
> 1. Create an "integrationtest" directory tree in src that is a sibling
> to the unit tests in "test".  The integrationtest directory will have a
> java subdir for the source code, a resources directory for non-compiled
> files that need to be in the classpath, and a data directory that
> contains the files and instructions necessary for setting up the
> external resources.

An idea: Why don't you create a separate subproject to run your integration
tests that you would put in src/test?

> 2. Create "integrationtest:xxx" goals in the project's maven.xml that
> correspond to the test plugin goals the set the test plugin properties
> to point to the integrationtest directory then run the corresponding
> test goal.
> 
> Thanks,
> ..David..

-Vincent





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

RE: Running integration tests

[Vincent Massol]

> -Original Message-
> From: David Jackman [mailto:[EMAIL PROTECTED]
> Sent: vendredi 13 mai 2005 18:32
> To: Maven Users List
> Subject: Running integration tests
> 
> For one of my projects, I need to add some integration tests that are
> separate from the unit tests.  The unit tests work as they should--they
> are fully automated and run with every build.  The integration tests are
> different in that they can't be fully automated since they depend on
> some external resources (in this case a specifically configured server)
> being available.

Why can't this be automated? Maybe Cargo (http://cargo.codehaus.org) could
help?

http://tinyurl.com/8djb
http://tinyurl.com/dnll2
http://tinyurl.com/btmwa

>  However, when these resources are in place I would
> like to be able to use Maven to run the tests.  I didn't see a plugin
> that directly addresses this situation, but did notice the
> "integrationUnitTestSourceDirectory" element of the POM that has been
> documented as deprecated.  Is anyone out there doing this sort of thing?
> Is there a best practice I can follow for the fewest headaches?

Maybe the Cargo Maven plugin?
 
> Here was my planned approach:
> 1. Create an "integrationtest" directory tree in src that is a sibling
> to the unit tests in "test".  The integrationtest directory will have a
> java subdir for the source code, a resources directory for non-compiled
> files that need to be in the classpath, and a data directory that
> contains the files and instructions necessary for setting up the
> external resources.

An idea: Why don't you create a separate subproject to run your integration
tests that you would put in src/test?

> 2. Create "integrationtest:xxx" goals in the project's maven.xml that
> correspond to the test plugin goals the set the test plugin properties
> to point to the integrationtest directory then run the corresponding
> test goal.
> 
> Thanks,
> ..David..

-Vincent





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

Re: Running integration tests

[dan tran]

You integration project surely depends on the main project.
that is why when ever you make changes in main project 
you must run jar:install to place its jar into local respository
and the integration to pickit up automatically.

Also, when ever you have to multiple projects collabrating together,
use maven-multiproject-plugin.

For your case

root
   main
   integration   (depending on main)


What you mean "hardcoding the jars' location"?

It should be picked up automatically by the integration project.

-D





On Fri, 18 Mar 2005 12:47:37 +0100, Ralph Pöllath <[EMAIL PROTECTED]> wrote:
> Thanks Dan.
> 
> I set up a separate project as you suggested, which includes a
> dependency on the main project.
> 
> This works fine, but it requires me to jar:install my main project each
> time I run the integration tests.
> 
> So I'd like to make the integration tests a subproject and add a
> dependency on the parent project's jar. Is that possible without
> hardcoding the jar's location?
> 
> Cheers,
> -Ralph.
> 
> On 02.03.2005, at 19:02, dan tran wrote:
> > Ralph,
> >
> > I would add another project to house your integration test cases.
> > The source of the testcase must stay in the main source directory.
> > (not the unit test src)
> >
> > After that, use jelly/java to drive your integration in maven.xml
> >
> > -D
> >
> > On Wed, 2 Mar 2005 17:42:31 +0100, Ralph Pöllath <[EMAIL PROTECTED]>
> > wrote:
> >> Hi,
> >>
> >> In addition to my unit tests, I have some integration tests which I'd
> >> like to be able to run separately (they require a database to be
> >> available, etc).
> >>
> >> What's the preferred way to do this with maven?
> >>
> >> Thanks,
> >> -Ralph.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

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

Re: Running integration tests

[Ralph Pöllath]

Thanks Dan.
I set up a separate project as you suggested, which includes a 
dependency on the main project.

This works fine, but it requires me to jar:install my main project each 
time I run the integration tests.

So I'd like to make the integration tests a subproject and add a 
dependency on the parent project's jar. Is that possible without 
hardcoding the jar's location?

Cheers,
-Ralph.
On 02.03.2005, at 19:02, dan tran wrote:
Ralph,
I would add another project to house your integration test cases.
The source of the testcase must stay in the main source directory.
(not the unit test src)
After that, use jelly/java to drive your integration in maven.xml
-D
On Wed, 2 Mar 2005 17:42:31 +0100, Ralph Pöllath <[EMAIL PROTECTED]> 
wrote:
Hi,
In addition to my unit tests, I have some integration tests which I'd
like to be able to run separately (they require a database to be
available, etc).
What's the preferred way to do this with maven?
Thanks,
-Ralph.

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

Re: Running integration tests

[Ralph Pöllath]

I was hoping for something like this (which doesn't work BTW :-)
// maven.xml








Any ideas?
Cheers,
-Ralph.
On 02.03.2005, at 19:02, dan tran wrote:
Ralph,
I would add another project to house your integration test cases.
The source of the testcase must stay in the main source directory.
(not the unit test src)
After that, use jelly/java to drive your integration in maven.xml
-D
On Wed, 2 Mar 2005 17:42:31 +0100, Ralph Pöllath <[EMAIL PROTECTED]> 
wrote:
Hi,
In addition to my unit tests, I have some integration tests which I'd
like to be able to run separately (they require a database to be
available, etc).
What's the preferred way to do this with maven?
Thanks,
-Ralph.

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

Re: Running integration tests

[dan tran]

Ralph,

I would add another project to house your integration test cases.
The source of the testcase must stay in the main source directory.
(not the unit test src)

After that, use jelly/java to drive your integration in maven.xml


-D



On Wed, 2 Mar 2005 17:42:31 +0100, Ralph Pöllath <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> In addition to my unit tests, I have some integration tests which I'd
> like to be able to run separately (they require a database to be
> available, etc).
> 
> What's the preferred way to do this with maven?
> 
> Thanks,
> -Ralph.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

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