You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by David Medinets <me...@mtolive.com> on 2001/12/14 16:04:34 UTC
FYI - Code to automatically add Test classes to a TestSuite.
This note is for users of the Ant build tool. I've modified an AllTests
class to automatically add Test classes to a TestSuite by recursively
checking a directory hierarchy for classes with "test" or "Test" in their
names.
Contrary to suggestions, I like having all of my testing code in one
directory hierachy instead of spread throughout the codebase. However, my
Test class finder works with both methods. For the central approach the top
of the hierarchy is "com.cordiem.tests" (actually, your equivalent). For the
distribed approach use "com.cordiem" as the root of the hierarchy.
The url for the code is: http://affy.blogspot.com/
Please let me know if anything was unclear or if there was a better
approach.
David Medinets, Consultant, http://www.codebits.com
PS - if someone is on the JUnit mailing list, feel free to cross-post.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: FYI - Code to automatically add Test classes to a TestSuite.
Posted by David Jencks <da...@directvinternet.com>.
Well, I don't know much about it, but here is an example from the jboss
test suite.
<target name="tests-standard-unit" depends="jars">
<mkdir dir="${build.reports}"/>
<mkdir dir="${build.testlog}"/>
<junit dir="${module.output}"
printsummary="${junit.printsummary}"
haltonerror="${junit.haltonerror}"
haltonfailure="${junit.haltonfailure}"
fork="${junit.fork}"
timeout="${junit.timeout}"
jvm="${junit.jvm}">
<jvmarg value="${junit.jvm.options}"/>
<sysproperty key="jbosstest.deploy.dir" file="${build.lib}"/>
<sysproperty key="log4j.properties"
file="${build.resources}/log4j.properties"/>
<classpath>
<pathelement location="${build.classes}"/>
<pathelement location="${build.resources}"/>
<path refid="javac.classpath"/>
</classpath>
<formatter type="${junit.formatter.type}"
usefile="${junit.formatter.usefile}"/>
<batchtest todir="${build.reports}"
haltonerror="${junit.batchtest.haltonerror}"
haltonfailure="${junit.batchtest.haltonfailure}"
fork="${junit.batchtest.fork}">
<fileset dir="${build.classes}">
<include name="**/*UnitTestCase.class"/>
<!-- do not include the dyn loading or security tests -->
<exclude name="**/test/jrmp/test/DynLoadingUnitTestCase.class"/>
<exclude name="**/test/security/test/*"/>
</fileset>
</batchtest>
</junit>
</target>
Anyway, the batchtest element seems to accept a fileset where you can
include and exclude whatever you want. This creates an xml file for each
test (that doesn't timeout or maybe crash really badly), which we then turn
into a nice website using some xslt.
<gripe> Anyone know how to fix this so tests that time out are noticed as
having failed???</gripe>
david jencks
On 2001.12.14 13:15:22 -0500 David Medinets wrote:
> > -----Original Message-----
> > From: David Jencks [mailto:davidjencks@directvinternet.com]
> >
> > What advantage does this offer over using batchtests with wildcards?
>
> I have no idea. What are batchtests and wildcards? Sometimes it's easier
> me
> to code a solution than to read the documentation <sigh>
>
> David Medinets, Consultant, http://www.codebits.com
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: FYI - Code to automatically add Test classes to a TestSuite.
Posted by T Master <tm...@iknowledgeinc.com>.
----- Original Message -----
From: "David Medinets" <me...@mtolive.com>
> I have no idea. What are batchtests and wildcards? Sometimes it's easier
me
> to code a solution than to read the documentation <sigh>
Don't worry. My quote of the week being spread around the office is:
"It's not ignorance if I didn't know"
:-D
T Master
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: FYI - Code to automatically add Test classes to a TestSuite.
Posted by T Master <tm...@iknowledgeinc.com>.
----- Original Message -----
From: "David Medinets" <me...@mtolive.com>
> I have no idea. What are batchtests and wildcards? Sometimes it's easier
me
> to code a solution than to read the documentation <sigh>
That sounds so funny!
:D
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: FYI - Code to automatically add Test classes to a TestSuite.
Posted by David Medinets <me...@mtolive.com>.
> -----Original Message-----
> From: David Jencks [mailto:davidjencks@directvinternet.com]
>
> What advantage does this offer over using batchtests with wildcards?
I have no idea. What are batchtests and wildcards? Sometimes it's easier me
to code a solution than to read the documentation <sigh>
David Medinets, Consultant, http://www.codebits.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: FYI - Code to automatically add Test classes to a TestSuite.
Posted by David Jencks <da...@directvinternet.com>.
What advantage does this offer over using batchtests with wildcards?
david jencks
On 2001.12.14 10:04:34 -0500 David Medinets wrote:
> This note is for users of the Ant build tool. I've modified an AllTests
> class to automatically add Test classes to a TestSuite by recursively
> checking a directory hierarchy for classes with "test" or "Test" in their
> names.
>
> Contrary to suggestions, I like having all of my testing code in one
> directory hierachy instead of spread throughout the codebase. However, my
> Test class finder works with both methods. For the central approach the
> top
> of the hierarchy is "com.cordiem.tests" (actually, your equivalent). For
> the
> distribed approach use "com.cordiem" as the root of the hierarchy.
>
> The url for the code is: http://affy.blogspot.com/
>
> Please let me know if anything was unclear or if there was a better
> approach.
>
> David Medinets, Consultant, http://www.codebits.com
>
> PS - if someone is on the JUnit mailing list, feel free to cross-post.
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>