You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rodney Waldhoff <rw...@icarus.apache.org> on 2002/10/31 17:52:48 UTC
[collections] maven test versus ant test
I notice that with collections at least, and probably other mavenized
commons projects, the command "ant test" and the command "maven test" run
different test suites.
On the ant side (build.xml), "ant test" runs the test suite defined by
org.apache.commons.collections.TestAll.
On the maven side (project.xml), "maven test" runs a suite of tests
defined (it seems) as everything under src/test, modulo a fairly
large number of abstract and TestAll classes enumerated in the project.xml
file. (And by the way, currently it seems there are at least some tests
not hooked in to the TestAll chain, notably ClassMap).
I think it's pretty obvious that we should keep the suites run by "ant
test" and "maven test" in sync, but I think I can justify it too: (1) gump
is running ant test, and so will not pick up failures if the two aren't in
sync (which is what's happening right now--TestClassMap fails, but gump's
not reporting it); (2) some developers are gonna use ant, some developers
are gonna use maven, so if the two test target/goals aren't in sync, we're
not all running the same tests.
The simplest way to cause this, it seems to me, is to simply include
"org/apache/commons/collections/TestAll.java" under <unitTest>, rather
than trying to enumerate the exclusions, which means developers need to
add an addTest call to TestAll when adding new TestCase classes (which is
a feature IMO). This also changes the output so we see the results of the
whole suite summarized rather than TestCase by TestCase results. Any
complaints or alternative solutions?
On a related note, one feature of the ant-based builds that I miss dearly
in maven is the "test.entry" convention, which allows one to call:
ant test
- to run all tests
ant -Dtest.entry=org.apache.commons.foo.TestBar test
- to run the tests in TestBar only
ant -Dtest.entry=org.apache.commons.foo.TestAll test
- to run all the tests in the foo package
which is extremely convienient when working with large test suites, or
when you're making rapid changes to a small set of classes. I presume
there is some what to do something similiar with maven?
- Rod
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [collections] maven test versus ant test
Posted by di...@multitask.com.au.
Rodney Waldhoff <rw...@apache.org> wrote on 01/11/2002 08:58:38 AM:
> Thanks dion. Can you describe "maven test:single-test" in more detail,
or
> point me to some docs on it?
Ah, the maven documentation :) That one's still on my todo list, but,
here's a short description:
To run a single unit test via Maven, use:
maven -Dtestcase=MyTest test:single-test
where MyTest is the class name of the test to execute.
>
> > You can do this @ the moment using maven test:single-test. I can add a
> > target for that sort of thing into the generated ant build.xml file it
you
> > want...
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [collections] maven test versus ant test
Posted by Rodney Waldhoff <rw...@apache.org>.
Thanks dion. Can you describe "maven test:single-test" in more detail, or
point me to some docs on it?
> You can do this @ the moment using maven test:single-test. I can add a
> target for that sort of thing into the generated ant build.xml file it you
> want...
> --
> dIon Gillard, Multitask Consulting
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [collections] maven test versus ant test
Posted by di...@multitask.com.au.
Rodney Waldhoff <rw...@icarus.apache.org> wrote on 01/11/2002 03:52:48
AM:
> I notice that with collections at least, and probably other mavenized
> commons projects, the command "ant test" and the command "maven test"
run
> different test suites.
>
> On the ant side (build.xml), "ant test" runs the test suite defined by
> org.apache.commons.collections.TestAll.
>
> On the maven side (project.xml), "maven test" runs a suite of tests
> defined (it seems) as everything under src/test, modulo a fairly
> large number of abstract and TestAll classes enumerated in the
project.xml
> file. (And by the way, currently it seems there are at least some tests
> not hooked in to the TestAll chain, notably ClassMap).
>
> I think it's pretty obvious that we should keep the suites run by "ant
> test" and "maven test" in sync, but I think I can justify it too: (1)
gump
> is running ant test, and so will not pick up failures if the two aren't
in
> sync (which is what's happening right now--TestClassMap fails, but
gump's
> not reporting it); (2) some developers are gonna use ant, some
developers
> are gonna use maven, so if the two test target/goals aren't in sync,
we're
> not all running the same tests.
+1 for keeping in synch.
> The simplest way to cause this, it seems to me, is to simply include
> "org/apache/commons/collections/TestAll.java" under <unitTest>, rather
> than trying to enumerate the exclusions, which means developers need to
> add an addTest call to TestAll when adding new TestCase classes (which
is
> a feature IMO). This also changes the output so we see the results of
the
> whole suite summarized rather than TestCase by TestCase results. Any
> complaints or alternative solutions?
+1 on the change.
> On a related note, one feature of the ant-based builds that I miss
dearly
> in maven is the "test.entry" convention, which allows one to call:
> ant test
> - to run all tests
> ant -Dtest.entry=org.apache.commons.foo.TestBar test
> - to run the tests in TestBar only
> ant -Dtest.entry=org.apache.commons.foo.TestAll test
> - to run all the tests in the foo package
> which is extremely convienient when working with large test suites, or
> when you're making rapid changes to a small set of classes. I presume
> there is some what to do something similiar with maven?
You can do this @ the moment using maven test:single-test. I can add a
target for that sort of thing into the generated ant build.xml file it you
want...
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>