Ant Intro
I’ve been coming across references to Ant over the past while, often while looking up info on code deployment and testing. I never really cottoned on to what it actually was before today – when I had a chance to look into using it to help me automate some load testing.
In a nutshell, Ant is a build management tool. That’s what you’ll hear it referred to, and that is due to the fact that it started out as a way to build the Tomcat web server, i.e. compile and package the Java code that was/is Tomcat.
However, it is much more than this, and is used to automate anything that can be described in terms of tasks and actions.
You could actually argue that it’s a type of XML meta language, i.e. a way to program tasks in another language (usually Java). It’s completely XML based and has a large number of core tasks such as javac, mkdir and jar. There are also lots of tasks contributed by the other projects knowing that their users probably use Ant too, such as jmeter – which I use for load testing. This XML file executed by Ant is always referred to as a ‘build’ file – despite that fact that you might be doing something completely different.
Here is an example of a simple build file taken from the Ant manual, which is excellent.
Automating Load Tests
However, I wasn’t interested in building projects, I was interested in automating my JMeter load testing. I had a number of tests that I wished to run every night when things were quiet. JMeter tests are run using a nice GUI so I started thinking about some way to run tests from the command line, and whilst looking into that it occurred to me that this might be a good opportunity to use a Ant in anger.
A bit more searching found me this IBM document that describes how to use Ant to automate JMeter load testing. The key is the sample build file ([JMETER_HOME]\extras\build.xml) and a jar of JMeter tasks ([JMETER_HOME]\extras\ant-jmeter-1.0.9.jar) for Ant that actually comes with the JMeter install.
The jar file just goes someplace that Ant can find it – I kept it with the build file I was working on as I wanted both in my repository when I was finished. But you could add it to the [ANT_HOME]/lib directory if you prefer.
So armed with these details and the example we were in business. I was able to simplify that example and include two separate tests in it.
So once you are setup, just run it from the command line:
ant build.xml
Or if you named your build file something different:
ant -buildfile my-load-test.xml
Powerful Stuff
It’s a powerful tool – I was able to wait between the load testing jobs in my build file (to allow the web server to recover):
<sleep seconds="10" />
And create directories with a timestamp to store the results in:
<!-- Create timestamp property -->
<tstamp>
<format property="timestamp.dir" pattern="yyyy-MM-dd" />
</tstamp>
<!-- Create the new directory for this set of results -->
<mkdir dir="${testpath}\Automated Results\${timestamp.dir}"/>
In case you are using JMeter too – I decided not to use the example’s suggestion of using XLST to convert the XML report to HTML. Instead we decided to write the XML to disk and parse it with our application server (ColdFusion 9). That way we can insert the details into our database for later analysis and graphing (cos I love graphs).
If you are playing around with the JMeter XML output files and you are wondering what the different attributes mean, then check out this guide.
Conclusion
Ant – I would say dive in and play around with it – there are lots of resources out there. And – just in case you wondering – Ant means ‘Another Neat Tool’ apparently and it’s certainly something we’ll be keeping in mind for future automation tasks.
Fly Dillon Fly 