« Return to Thread: RE: EJB Unit tests with Maven 2

Re: RE: EJB Unit tests with Maven 2

by PeteTh :: Rate this Message:

| View in Thread

Matt,
 
Following my approach for your case I would have :-
 
+ application-root  
     pom.xml   (normal parent pom)
    
   now normal project artifacts follows e.g. :- 
  
    + normal EAR
    + normal JAR(s)
    + normal WARs
    + test WAR (for JUnitEE or Cactus)

   now the M2 project modules to run the integration tests e.g. :-
  
    + runtests-integration
         pom.xml   (sub-parent pom, invoking child modules in the order below)
        + rebuild-database
               pom.xml  (antrun to rebuild DB schema)
        + start-container 
               pom.xml  (use cargo plugin to start container - bind to integration-test phase )  

I used Ant here to start OC4J just using the Antrun plugin to invoke a bat file that starts OC4J (passing a few parameters) so my pom.xml won't really help you, also use Ant to check container is ready (<waitfor> task  e.g.
 
   <waitfor maxwait="180" maxwaitunit="second" checkevery="3" checkeveryunit="second" timeoutproperty="container.unavailable">
             <http url=" http://${appserver.host}:${appserver.http.port}"/>
    </waitfor>.
 
If you don't want the container to start during normal builds, then wrap the cargo <plugin> in a <profile> so that it is only active when -Pintegrationtests  is supplied.  
 

        + runtests-serverside  (runs junits needing server started as they invoke remote interfaces)
               pom.xml (surefire:test only picking up tests ending in *ServerTest.java )

e.g.

 <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-plugin</artifactId>
      <executions>
       <execution>
        <id>run server side JUnits from tests_Serverside</id>
        <phase>integration-test</phase>
        <configuration>
         <reportFormat>xml</reportFormat>
         <includes>
          <include>**/*ServerTest.java </include>
         </includes>
         <testClassesDirectory>../tests_Serverside/target/test-classes</testClassesDirectory>
         <classesDirectory>../tests_Serverside/target/classes</classesDirectory>
        </configuration>
        <goals>
         <goal>test</goal>
        </goals>
       </execution>


        + runtests-incontainer-tests
               pom.xml (antrun for running JUnitEE or Cactus incontainer tests)

This uses the Antrun plugin to call the <Junitee> ant task. The 'test WAR' artifact (buillt as normal) has a dependency on the jar that contains the JUnitEE test cases. So here I just configure <junitee> via ant giving it the URL of the web app and resource="${ inContainerTests.jar.name}". I don't have the pom.xml handy right now. I make sure the test results output todir= goes to the same directory surefire. So that reporting all works.


        + stop-container
               pom.xml ( just configure the cargo M2 plugin bound to integration-test to stop the container)

Again here I can't use Cargo so use ant to invoke the Oc4j admin jar to stop container.

I have another M2 module in addition to those shown above that actually hold the integration tests :-

    + tests-Serverside 
         pom.xml   (JAR pom, building those JUnits needing server started)
        
           The JUnits in this project follow two naming patterns :-
           src/test/java
                 *ServerTest.java  (JUnits needing server started as they invoke remote interfaces )
                 *JEETest.java       (JUnits needing to run inside container via JUnitEE or cactus )

     The above JAR could probably have been split into two separate JARs for each type.
    
     The parent pom.xml overrides the default maven-surefire-plugin by excluding the following :-
    
     <excludes>
      <exclude>**/*ServerTest.java</exclude>
      <exclude>**/*JEETest.java</exclude>
     </excludes>
    
     such that these tests don't get run during the normal test phase. Just regular standalone * Test.java get run.
    

Hope this is useful


 
On 11/02/06, Matt Raible <mraible@...> wrote:
Is it possible to share your pom.xml (s)?  I'd like to reproduce the
following from my build.xml with pom.xml (if possible):

   <target name="test-tomcat" depends="war"
       description="Starts Tomcat, runs jWebUnit tests, stops Tomcat">

       <taskdef resource="cargo.tasks " classpathref="test.classpath"/>

       <cargo containerId="${cargo.server}" id="cargo.server"
home="${server.home}"
           output="${test.dir}/cargo.log" action="start">
           <configuration dir="${test.dir}/${cargo.server}">
               <deployable type="war"
file="${basedir}/${dist.dir}/${webapp.name}.war"/>
           </configuration>
       </cargo>

       <antcall target="test-web"/>

       <cargo refid="cargo.server" action="stop"/>
   </target>

   <target name="test-web" depends="compile"
       description="Runs jWebUnit tests in a running server">
       <property name="testcase" value="WebTest"/>
       <antcall target="test"/>
   </target>

   <target name="test" depends="compile" description="Runs JUnit tests">
       <!-- Check that junit.jar is in $ANT_HOME/lib -->
       <available classname="junit.framework.TestCase"
property="junit.present"/>
       <fail unless="junit.present"
           message="Please copy web/WEB-INF/lib/junit.jar into
${env.ANT_HOME}/lib"/>

       <mkdir dir="${test.dir}/data"/>
       <junit printsummary="no" fork="true" forkmode="once"
           errorProperty=" test.failed" failureProperty="test.failed">
           <classpath>
               <path refid="compile.classpath"/>
               <path refid="test.classpath"/>
               <path location="${build.dir}/classes"/>
               <path location="${test.dir}/classes"/>
               <path location="web/WEB-INF/classes"/>
               <path location="web"/>
               <fileset dir="web/WEB-INF/lib" includes="*.jar"/>
           </classpath>
           <formatter type="xml"/>
           <formatter type="brief" usefile="false"/>
           <batchtest todir="${test.dir}/data" if="testcase">
               <fileset dir="${test.dir }/classes">
                   <include name="**/*${testcase}*"/>
                   <exclude name="**/*TestCase.class"/>
                   <exclude name="**/*$*.class"/>
               </fileset>
           </batchtest>
           <batchtest todir="${test.dir}/data" unless="testcase">
               <fileset dir="${test.dir}/classes">
                   <include name="**/*Test.class*"/>
                   <exclude name="**/*WebTest.class"/>
               </fileset>
           </batchtest>
       </junit>

       <fail if="test.failed">
         Unit tests failed. For error messages, check the log files in
         ${test.dir}/data or run "ant test-reports"
         to generate reports at ${ test.dir}/reports.</fail>
   </target>

Thanks,

Matt

On 2/11/06, Pete <petelists@...> wrote:

> I have achieved integration testing (both JunitEE/Cactus and JUnits calling
> remote interfaces) in M2 using a very simple lightweight POM for each
> discrete task/execution in the integration phase e.g.
>
> + runtests-integration
>      pom.xml   (parent pom, invoking child modules in the order below)
>     + rebuild-database
>            pom.xml  (antrun)
>     + start-container
>            pom.xml  (antrun or cargo)
>     + runtests-serverside  (runs junits needing server started as they
> invoke remote interfaces)
>            pom.xml (surefire:test)
>     + runtests-incontainer-tests
>            pom.xml (antrun for running JUnitEE or Cactus incontainer tests)
>     + stop-container
>            pom.xml (antrun or cargo)
>
> All plugins above bound to the integration-test phase
>
> I found this approach also necessary, because you can only have one instance
> of the antRun plugin for the integration-test phase, therefore you can't use
> antrun, then surefire, then antrun again  as the last antrun overrides the
> first if they are bound to the same phase.
>
> I did want to use Cargo, but unfortunately there was no support for OC4J
> with an existing configuration.
>
> I have the above 'runtests-integration' suite only execute if the M2 build
> profile is set to -Pintegrationtests. In this way developers can run a
> regular M2 build which just runs standalone JUnits, or specify the profile
> to run a fuller build. We have CruiseControl always running the integrations
> tests profile.
>
> With m2.02 I should now convert the Antruns to Ant Plugins.
>
> I'm hoping that when M2 supports integration tests more I can migrate to the
> approved strategy, but this works right now, we have Applications (both
> EARs) that are built with M2 via CruiseControl, the above integration
> projects start the container run all the integration tests (with the 2nd EAR
> application even invoking the 1st EAR's services)
>
> I have two other M2 modules in addition to those shown above that actually
> hold the integration tests :-
>
> + tests-serverside
>
>      pom.xml   (JAR pom, building those JUnits needing server started as
> they invoke remote interfaces)
> + tests-incontainer
>      pom.xml  (JAR pom, building those JUnits needing to run inside
> container JUnitEE or cactus)
>
> Pete
>
>
>
> On 29/01/06, Maciej Mastalarczuk <maciekm@...> wrote:
> > Hi Vincent,
> >
> > > Yeah, I understand how confusing it can be because the new maven2
> > > repository
> > > on ibiblio aggregates both m1 and m2 stuff so the old stuff are in
> cargo/
> > > and the new ones in org/codehaus/cargo.
> >
> > Interesting is the fact that this m1 stuff is under maven2 directory:
> > http://www.ibiblio.org/maven2/cargo/cargo/, which is what
> actually confused
> > me.
> >
> > But not to worry, I will never make the same mistake again. I guess one of
> > the best practices for a Maven newbie would be to make sure to always get
> > the right groupId and artifactId instead of guessing or speculating (which
> > is what I did).
> >
> > And thanks for putting it on the webpage, should help the beginners.
> Indeed
> > you have had all the necessary information of the page, just when someone
> > makes a quick start with m2, it's easy to miss some of it and bang! - you
> > are on the wrong track :-)
> >
> > Anyway, I'll get busy with cargo and EJB testing and you'll probably hear
> > from me again :-)
> >
> > Thanks again and regards
> >
> > Maciej
> >
> >
>
>

 « Return to Thread: RE: EJB Unit tests with Maven 2