Initially all tests for Ant tasks were written as individual + JUnit test cases. Pretty + soon it was clear that most tests needed to perform common tasks + like reading a build file, intializing a project instance with + it and executing a target. At this point BuildFileTest + was invented, a base class for almost all task test cases.
+ +BuildFileTest works fine and in fact has been picked up by the Ant-Contrib Project + and others as well.
+ +Over time a new pattern evolved, more and more tests only
+ executed a target and didn't check any effects. Instead that
+ target contained the assertions as a <fail>
+ task. This is an example taken from the build file for the
+ ANTLR task (using Ant 1.7 features):
where the corresponding JUnit testcase has been reduced + to
+ +This approach has a couple of advantages, one of them is that + it is very easy to translate an example build file from a bug + report into a test case. If you ask a user for a testcase for a + given bug in Ant, he now doesn't need to understand JUnit or how + to fit a test into Ant's existing tests any more.
+ +AntUnit takes this approach to testing even further, it
+ removes JUnit completely and it comes with a set of predefined
+ <assert> tasks in order to reuse common kind
+ of checks.
It turns out that AntUnit lends itself as a solution to other + problems as well. The assertions are an easy way to validate a + setup before even starting the build process, for example. + AntUnit could also be used for functional and integration tests + outside of the scope of Ant tasks (assert contents of databases + after running an application, assert contents of HTTP responses + ...). This is an area that will need more research.
+The <antunit> task drives the tests much like + <junit> does for JUnit tests.
+ +When called on a build file, the task will start a new Ant + project for that build file and scan for targets with names + that start with "test". For each such target it then will
+The base task is <assertTrue>. It
+ accepts a single nested condition and throws a subclass of
+ BuildException named AssertionFailedException if that
+ condition evaluates to false.
This task could have been implemented using
+ <macrodef> and <fail>,
+ but in fact it is a "real" task so that it is possible to
+ throw a subclass of BuildException. The
+ <antunit> task catches this exception and
+ marks the target as failed, any other type of Exception
+ (including other BuildException) are test errors.
Together with <assertTrue> there are
+ many predefined assertions for common conditions, most of
+ these are only macros.
The <logcapturer> captures all messages
+ that pass Ant's logging system and provides them via a
+ reference inside of the project. If you want to assert
+ certain log messages, you need to start this task (prior to
+ your target under test) and use the
+ <assertLogContains> assertion.
<expectFailure> is a task container that
+ catches any BuildException thrown by tasks nested into it. If
+ no exception has been thrown it will cause a test failure (by
+ throwing an AssertionFailedException).
Part of the library is the AntUnitListener
+ interface that can be used to record test results. The
+ <antunit> task accepts arbitrary many listeners and
+ relays test results to them.
Currently only a single implementation
+ <plainlistener> modelled after the "plain"
+ JUnit listener is bundeled with the library.
This is a way to test that <touch>
+ actually creates a file if it doesn't exist:
When running a task like
+ +from a buildfile of its own you'll get a result that looks like
+ +This library doesn't strive to replace NAnt or MSBuild, its + main purpose is to help those of us who work on projects + crossing platform boundaries. With this library you can use Ant + to build and test the Java as well as the .NET parts of your + project.
+ +This library provides a special version of the
+ <exec> task tailored to run .NET executables.
+ On Windows it will assume the Microsoft framework is around and
+ run the executable directly, while it will invoke Mono on any
+ other platform. Of course you can override these
+ assumptions.
Based on this a few tasks to run well known .NET utilities + from within Ant are provided, namely tasks to run NUnit, NAnt and MSBuild.
+ +There also is some experimental Wix task, but it probably doesn't + do anything useful at all.
+Runs a .NET executable.
+Runs NUnit tests.
+Invokes NAnt, either on an external file or a build file + snippet contained inside your Ant build file.
+Invokes MSBuild, either on an external file or a build file + snippet contained inside your Ant build file.
+runs NAnt on the embedded <echo>
+ task, output looks like
runs MSBuild on the embedded <Message>
+ task, output looks like