integration tests

[Stephen Haberman <st...@beachead.com>]

Hi,

I'm working on a webapp where I've got a bunch of domain model unit
tests in src/test and then want to put some HttpUnit integration
tests in something like src/iu-test or src/web-test.

I was hoping to use the pom's integrationUnitTestDirectory element,
but it seems to be no longer used? Does anyone have a best practice
way of going about having two different sets of JUnit tests?

After giving up on finding a nice, built-in way, I copied some of
the Jelly code out of test's plugin.jelly and tried to do this in my
own goal in maven.xml:

    <taskdef
      name="junit"
      classname="org.apache.tools.ant.taskdefs.optional.junit.JUnitTask">
      <classpath>
        <pathelement path="${pom.getDependencyPath('ant')}"/>
        <pathelement path="${pom.getDependencyPath('ant+optional')}"/>
        <pathelement path="${pom.getDependencyPath('junit')}"/>
      </classpath>
    </taskdef>
    <junit
      ...snip... />

But the taskdef fails with a NoClassDefFoundError for
junit.framework.TestListener, even though the
pom.getDependencyPath('junit') line should import junit just as it
does (and works) for a javac task prior to this taskdef.

My naive thinking is that this is some classloader issue that is
being/will be worked out, but I've tried it with beta-8 and HEAD to
no avail and can't think of a work around other than manually
calling JUnit via the java task. But ideally I'd like to avoid it.

Is there an easier way to do this that I'm not just seeing?

Thanks,
Stephen

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

Re: integration tests

[Stephen Haberman <st...@beachead.com>]

Cool, thanks for the code snippet, it's working really well.

- Stephen

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

RE: integration tests

[David Zeleznik <dz...@ilog.com>]

FYI, there was some discussion on this issue a while back. But currently,
the integrationUnitTest elements of the pom are not being used anywhere. We
wrote this little hack that seems to be working well for us:

  <goal name="filterTests">
    <j:set var="testModeX" value="${maven.test.mode}X" />
    <j:if test="${testModeX == 'X'}" >
      <j:set var="maven.test.mode" value="all" />
    </j:if>
    <echo>Running ${maven.test.mode} tests</echo>
    <j:if test="${maven.test.mode != 'all'}" >
      <j:set var="includeProp" value="test.${maven.test.mode}.includes" />
      <j:if test="${context.getVariable(includeProp) != null}">
        <u:tokenize var="patterns"
delim=",">${context.getVariable(includeProp)}</u:tokenize>
        <j:forEach var="pattern" items="${patterns}">
          <j:set var="dummy"
value="${pom.build.unitTest.addInclude(pattern)}" />
        </j:forEach>
      </j:if>
      <j:set var="excludeProp" value="test.${maven.test.mode}.excludes" />
      <j:if test="${context.getVariable(excludeProp) != null}">
        <u:tokenize var="patterns"
delim=",">${context.getVariable(excludeProp)}</u:tokenize>
        <j:forEach var="pattern" items="${patterns}">
          <j:set var="dummy"
value="${pom.build.unitTest.addExclude(pattern)}" />
        </j:forEach>
      </j:if>
    </j:if>
  </goal>

This allows us to use the unitTest element of the pom to define the
inclusive fileset of all tests that can be run against the project. We then
allow to run named test subsets by setting the maven.test.mode property. For
example, if you set maven.test.mode=quickanddirty, then you can have
additional includes and excludes defined in your project properties:

  test.quickanddirty.excludes = **/lengthytests/**, ...
  test.quickanddirty.includes  = **/only-the-quick-tests/**

We then attach filterTests as a preGoal of test:test. Right now, we are only
supporting the default "all" and the optional "smoke" test modes. But the
mechanism is extensible to support any number of named test modes. Hope this
helps you out.

--------------------------------------
David Zeleznik
ILOG - Changing the rules of business
mailto:dzeleznik@ilog.com
http://www.ilog.com
--------------------------------------

> -----Original Message-----
> From: Stephen Haberman [mailto:stephen@beachead.com]
> Sent: Wednesday, April 02, 2003 1:11 PM
> To: users@maven.apache.org
> Subject: integration tests
>
>
> Hi,
>
> I'm working on a webapp where I've got a bunch of domain model unit
> tests in src/test and then want to put some HttpUnit integration
> tests in something like src/iu-test or src/web-test.
>
> I was hoping to use the pom's integrationUnitTestDirectory element,
> but it seems to be no longer used? Does anyone have a best practice
> way of going about having two different sets of JUnit tests?
>
> After giving up on finding a nice, built-in way, I copied some of
> the Jelly code out of test's plugin.jelly and tried to do this in my
> own goal in maven.xml:
>
>     <taskdef
>       name="junit"
>       classname="org.apache.tools.ant.taskdefs.optional.junit.JUnitTask">
>       <classpath>
>         <pathelement path="${pom.getDependencyPath('ant')}"/>
>         <pathelement path="${pom.getDependencyPath('ant+optional')}"/>
>         <pathelement path="${pom.getDependencyPath('junit')}"/>
>       </classpath>
>     </taskdef>
>     <junit
>       ...snip... />
>
> But the taskdef fails with a NoClassDefFoundError for
> junit.framework.TestListener, even though the
> pom.getDependencyPath('junit') line should import junit just as it
> does (and works) for a javac task prior to this taskdef.
>
> My naive thinking is that this is some classloader issue that is
> being/will be worked out, but I've tried it with beta-8 and HEAD to
> no avail and can't think of a work around other than manually
> calling JUnit via the java task. But ideally I'd like to avoid it.
>
> Is there an easier way to do this that I'm not just seeing?
>
> Thanks,
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>


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