Running integration tests

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Running integration tests

David Jackman
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.  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?
 
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.
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..
 
Reply | Threaded
Open this post in threaded view
|

RE: Running integration tests

Vincent Massol


> -----Original Message-----
> From: David Jackman [mailto:[hidden email]]
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Running integration tests

thomasvdv
In reply to this post by David Jackman
Vincent,

Any plans on building Cargo support for WAS?

Cheers,
Thomas

On 5/13/05, Vincent Massol <[hidden email]> wrote:

>
>
>
> > -----Original Message-----
> > From: David Jackman [mailto:[hidden email]]
> > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

RE: Running integration tests

Vincent Massol


> -----Original Message-----
> From: Thomas Van de Velde [mailto:[hidden email]]
> 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 <[hidden email]> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: David Jackman [mailto:[hidden email]]
> > > 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[m2] bug in eclipse:eclipse

Nicolas Chalumeau
In reply to this post by thomasvdv
I find a bug in the eclipse pluggin and want to file it to jira but
where MNG or to the eclipse plugin one?

the bug is the the generate file are note portable like in the M1 plugin
path="C:/Documents and Settings/Nicolas/.m2/repository/...
the path is hard coded

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2] bug in eclipse:eclipse

Brett Porter
Hi Nicolas,

Please file it under MNG.

Thanks,
Brett

On 5/15/05, Nicolas Chalumeau <[hidden email]> wrote:

> I find a bug in the eclipse pluggin and want to file it to jira but
> where MNG or to the eclipse plugin one?
>
> the bug is the the generate file are note portable like in the M1 plugin
> path="C:/Documents and Settings/Nicolas/.m2/repository/...
> the path is hard coded
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Running integration tests

David Jackman
In reply to this post by 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:[hidden email]]
Sent: Friday, May 13, 2005 10:56 AM
To: 'Maven Users List'
Subject: RE: Running integration tests



> -----Original Message-----
> From: David Jackman [mailto:[hidden email]]
> 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: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[m2] ignore some report

Nicolas Chalumeau
I have a site module that contain no src java file?

The main project have no report and the list of report to generate are
only in the module sub project.

In all the module I have :

  <reports>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-project-info-reports-plugin</artifactId>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-checkstyle-plugin</artifactId>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-pmd-plugin</artifactId>
      </plugin>
    </plugins>
  </reports>

Even if the site pom I include or not the following section :
  <reports>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-project-info-reports-plugin</artifactId>
      </plugin>
    </plugins>
  </reports>

The pmd plugin try to generate its repport and fail

[INFO] [site:site]
[INFO] Generate pmd report.
[INFO] ----------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ----------------------------------------------------------------------------
[ERROR] Cause:
org.apache.maven.plugin.MojoExecutionException: Error during site generation
        at org.apache.maven.doxia.DoxiaMojo.execute(DoxiaMojo.java:181)
        at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.processGoals(DefaultLifecycleExecutor.java:169)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:90)
        at org.apache.maven.DefaultMaven.processProject(DefaultMaven.java:253)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:167)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:246)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:324)
        at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:303)
        at org.codehaus.classworlds.Launcher.launch(Launcher.java:243)
        at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:416)
        at org.codehaus.classworlds.Launcher.main(Launcher.java:363)
Caused by: java.lang.IllegalStateException: basedir
c:\TEMP\ts2-pm\refactoring\ts2-pm-site\src\main\java does not exist
        at org.codehaus.plexus.util.DirectoryScanner.scan(DirectoryScanner.java:539)
        at org.codehaus.plexus.util.FileUtils.getFileNames(FileUtils.java:1312)
        at org.codehaus.plexus.util.FileUtils.getFiles(FileUtils.java:1281)
        at org.codehaus.plexus.util.FileUtils.getFiles(FileUtils.java:1275)
        at org.apache.maven.plugin.pmd.PmdReport.getFilesToProcess(PmdReport.java:180)
        at org.apache.maven.plugin.pmd.PmdReport.execute(PmdReport.java:105)
        at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:66)
        at org.apache.maven.doxia.DoxiaMojo.execute(DoxiaMojo.java:146)
        ... 14 more

Is it some inherance issue ? And how to ignore some report in specific modules?

Nicolas

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [m2] ignore some report

Brett Porter
On 5/17/05, Nicolas Chalumeau <[hidden email]> wrote:
> org.apache.maven.plugin.MojoExecutionException: Error during site generation

Fix for PMD.

> Is it some inherance issue ? And how to ignore some report in specific modules?

We've been discussing this. Report inheritence is not currently
completely decided.

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]