The Artima Developer Community
Sponsored Link

Java Community News
AntUnit 1.0 Released

1 reply on 1 page. Most recent reply: Jan 9, 2007 2:17 PM by Steve Loughran

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 1 reply on 1 page
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

AntUnit 1.0 Released Posted: Jan 9, 2007 1:17 PM
Reply to this message Reply
AntUnit is an Ant library that allows the definition and execution of tests inside an Ant file. AntUnit grew out of the need to validate pre-conditions in a build file, and now provides assertion tags that can be used to execute tests in conjunction with simple Java test classes.

Test suites are often run as part of a build process. And when the build process is orchestrated by Ant, lots of test-related information gets embedded in Ant build files. Ant now has a new Antlib that makes test setup and execution easier. According to the project documentation for AntUnit 1.0:

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, initializing a project instance with it and executing a target. At this point BuildFileTest was invented, a base class for almost all task test cases...

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.

The above approach is illustrated with an example for a test for ANTLR that verifies the existence of five files:

  <target name="test3" depends="setup">
    <antlr target="antlr.g" outputdirectory="${tmp.dir}"/>
        <!-- to prove each of these files exists;
             ANTLR >= 2.7.6 leaves behind new (.smap) files as well. -->
        <resourcecount when="ne" count="5">
          <fileset dir="${tmp.dir}">
            <include name="CalcParserTokenTypes.txt" />
            <include name="" />
            <include name="" />
            <include name="" />
            <include name="" />

The above XML target is then used in conjunction with the following simple Java class:

public class ANTLRTest extends BuildFileTest {

    private final static String TASKDEFS_DIR = "src/etc/testcases/taskdefs/optional/antlr/";

    public ANTLRTest(String name) {

    public void setUp() {
        configureProject(TASKDEFS_DIR + "antlr.xml");

    public void tearDown() {

    public void test3() {

The AntUnit project page notes that the approach of inserting test snippets directly into Ant files can, in some cases, eliminate the need for standalone JUnit test classes:

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.

What do you think of AntUnit's approach to embedding test code directly in Ant files?

Steve Loughran

Posts: 9
Nickname: stevel
Registered: Feb, 2006

Re: AntUnit 1.0 Released Posted: Jan 9, 2007 2:17 PM
Reply to this message Reply
AntUnit is excellent! Anyone writing ant tasks should use it from now on to write their tests! It lets you write your tests in Ant itself, instead of mixing build files and JUnit test cases.

AntUnit is targeted at anyone writing Ant tasks. However, you can use almost any of its assertions in existing tasks. However, its real role is in testing tasks you write. My favourites are <expectfailure> and <assertLogContains>, the latter using a condition that only works under antunit runs, because it captures the log.

Heres an expected failure example from the forthcoming Ant in Action book:

<target name="testWeekdayCaseSensitive" depends="define">
expectedMessage="not a permitted value">
<book:weekday day="September"/>

AntUnit is very cool for script dev

<target name="echo-task-jython">
<scriptdef language="jython"
self.log("text: " +self.text)

<target name="testEcho" depends="echo-task-jython"
<s:echo>nested text</s:echo>
<au:assertLogContains text="text: nested text"/>

It has a limitation: the tests run in the same JVM. If you have singleton classes they can contaminate each other, and we have already found some odd cases where things behave differently under antunit than normal. and it is ant1.7+ only. If you have one of those problems, you can stick to ant-testutil, which is a subclass of JUnit's TestCase class with the extra logic to run a build in-VM and collect the results. It is how Ant's core is tested, how antunit bootstraps, and is distributed by way of the maven repository.

To summarize, developers of Ant tasks no longer have any excuse for not writing tests.

Steve Loughran
Member, Ant developer team.
Author, Ant in Action.

Flat View: This topic has 1 reply on 1 page
Topic: Martin Fowler on Role Interfaces Previous Topic   Next Topic Topic: Four Takes on Adding Ajax to a J2EE App

Sponsored Links


Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use