ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wascally Wabbit <>
Subject Re: Introducing AntUnit
Date Thu, 14 Apr 2005 14:04:21 GMT

I have already created such a beast using Ant; the project is
waiting to to be cleaned up before being posted on Sourceforge
(at antunit). I had planned to get to it before summer's end.
Not to beat my own drum but it does a full JUnitisque framework
in Ant. It has not been released yet so there aren't any
licensing issues (LGPL vs Apache,etc.). What are the chances of
you taking a look-see so work isn't duplicated? My AntUnit is
based on AntXtras (which does have licensing issues w/ LGPL)
but the AntUnit code ideas could be transferred w/o any problems?

Features like log capturing and evaluation is already done by
AntXtras/capture tasks. Assertions are handled by the
AntXtras/rules tasks. Error-condition testing is handled by the
AntXtras/protect tasks.

-Just an idea
The Wabbit

At 07:39 AM 4/14/2005, you wrote:
>inspired by the creative use of <macrodef> and <fail> others (mainly
>Matt and Steve) have shown in our tests, the idea of AntUnit we had a
>long time ago surfaced in my mind again.
>I've just dumped a little macrodef antlib (and one "real" task,
><assertTrue>) into our proposal area.  This is only a temporary place
>until my JIRA request for a subversion space for Ant[1] has been
>I simply lost patience and didn't want to have the code on my disk
>until the next head-crash.  And I also don't know when I'll find time
>to continue work on it, so I wanted to give others a chance to play
>with it.
>The idea is to create a unit test Ant library that uses Ant build
>files to test Ant.  Having assert tasks is only one part of it and it
>pretty much works the way that I've already shown (a very incomplete
>list of asserts we'll need is in antlib.xml).  Things like
>assertLogContaining will be more difficult to do.
>The other part will be an <antunit> task, which will take a build file
>and for each target whose name starts with "test" will
>(1) create an Ant task
>(2) run the target named setUp if present
>(3) run the target
>(4) run the target named tearDown if present
>It will support result formatters much like the JUnit task.  There
>will be passing and failing tests as well as tests that cause errors.
>To tell failures from errors, <assert*> throws a subclass of
>BuildException named AssertionFailedException.
>It may be better to fork a new VM, I'm not sure.  Reusing the Ant task
>would certainly be easier.
>What do you think?  Is this worth the effort?
>I came accross some issues that I'm going to raise in separete

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message