As I mentioned in another thread, this approach to unit testing for Ant
is much easier than junit testing. The concept is similar, but there is
no need to write Java code for tests. The tests are in build files,
several layers of indirection are avoided, and anyone who can write a
build file can write a test. Think of all the build file snippets from
the user list that people submit with problems that could easily be
turned into unit tests. Even better, each of these tests becomes a
working example that could be linked to the Ant documentation. I see
this as a big win.
I have written a similar system as part of Antelope, but I think
Stefan's implementation is cleaner. There are a few things I'd like to
see added to AntUnit:
1. better reporting, probably just need a more involved AntUnitListener.
2. support for a "suite" concept, that is, a way to group tests beyond
filesets. Might just need an "add(AntUnit)" method in AntUnit itself.
Include reporting per suite. Having a "name" attribute for each antunit
would also be useful for reporting.
3. a way to disable individual tests or disable entire suites.
Dale
Matt Benson wrote:
--- Martijn Kruithof <[EMAIL PROTECTED]> wrote:
Stefan Bodewig wrote:
I'd not be opposed against making antunit part of
the core, but so far
it hasn't attracted enough committers to even leave
the sandbox. And
the six months probation time is over, BTW.
FWIW, my feeling is that AntUnit _is_ where we (at
least I) want to get to, and I would desire that it be
exempted from the probation period on those grounds.
:)
Stefan
I think the using / maintaining by ourselves is more
of a chicken and
egg problem
- We do not really need it for our "outside ant"
activities
- We cannot really use it for our "inside ant"
activities as it is in
the sandbox.
- We do not maintain it as we do not use it, and it
is in the sandbox.
I agree 100% here. Ant is the place to prove AntUnit.
So do we make a build of AntUnit and include in
lib/optional in Ant core HEAD? (on another thread,
Martijn mentioned that we bundle a junit jar and
would/should handle AntUnit similarly; agreed, but
fetch.xml does have the capability to fetch the junit
jar as well)
I am in favour of
1) moving antunit part of the core
+0... we should be able to move the artifact to
lib/optional and make the tests conditional as w/
current... obviously we should also make the AntUnit
test path in build.xml separate from the JUnit path,
so we can slowly move tests from the latter to the
former.
2) start using this testing strategy by the tests of
core.
We sould only do 1 if we want to do 2 (and I think
we want to do 2)
I know I do. Basically more and more of us _have_
been using the au strategy, just without the
syntactic/semantic sugar it provides. :)
And we should only do 2 after we have done 1.
If we start doing 2 I am sure there will be enough
committers.
The current version of AntUnit probably has 80% or
better of the total test functionality. I think our
tests rely less and less on log messages and more on
results, etc. Log contents are probably the biggest
thing missing from au... we could write these, or just
change the logic of those tests (this decision might
require a vote). But my point is that "enough
committers" shouldn't amount to much. :)
-Matt
Martijn
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
