InfoQ

News

Autotest - a hidden tool gem

Posted by Werner Schuster on Dec 12, 2007 05:00 PM

Community
Ruby
Topics
Unit Testing,
Agile Techniques,
Programming
Tags
IDEs,
ZenTest,
Automation,
Testing
One of the secrets of the Ruby community is why many developers prefer  text editors over IDEs. One reason is the group of tools - written in Ruby - that help to automate a lot of the tedium of coding. Some of these tools were recently featured in a poll on Pat Eyler's blog

One of these tools is Autotest, part of the Zentest package. The installation is simple:
gem install zentest 
While Zentest helps you write unit tests and synchronize your code with them, Autotest does exactly one thing: once started, it will re-run the tests whenever a file is saved. It's clever about it and only runs the tests that are deal with code in the saved files.

Eric Hodel, the creator of Autotest, explains his mode of work that led him to write Autotest:
Before I wrote autotest I was making fine-grained saves that were syntactically correct. I wrote autotest to automate the running of tests so I wouldn't have to choose which tests to run. My changes were so small that I spent an annoying fraction of my time editing my command line.
This also mentions another benefit of running the tests: the code gets loaded and checked at every save. Compare this to modern Java IDEs, that run a big set of static analyzers such as syntax and semantic checkers over code, either incrementally or when a save happens. A similar level of automated checking is achieved with Autotest, while still leaving developers in their preferred editor.

A plugin interface also allows to extend Autotest. This is as simple as creating a ".autotest" file in the project root. In this, either require existing plugins, or write some custom handlers for various hooks:
Autotest.add_hook :red { |autotest|   p "Failures!" } 
The first parameter is the name of the hook this hooks into - in this case a test failure. This code will simply print out "Failures!" if the tests didn't pass. This also allows to invoke other tools, depending on the outcome of the tests or simply at every save. Plugins for integration with Emacs or acoustic feedback are available.

Have you heard of Autotest before? Are you considering to use it?

No comments

Reply

Exclusive Content

Agile and Beyond - The Power of Aspirational Teams

Tim Mackinnon talks about the aspirations behind the Agile principles and practices, the desire to become efficient, to write quality code which does not end up being thrown away.

Concurrency: Past and Present

Brian Goetz discusses the difficulties of creating multithreaded programs correctly, incorrect synchronization, race conditions, deadlock, STM, concurrency, alternatives to threads, Erlang, Scala.

ActionScript 3 for Java Programmers

Often the hardest part of changing technologies is language syntax differences. This new article provides Java developers with a transition guide to Actionscript which forms the foundation of Flex.

Neal Ford On Programming Languages and Platforms

Neal Ford talks about having multiple languages running on one of the two major platforms: Java and .NET. He also presents the advantages offered by Ruby compared to static languages like Java or C#.

Future Directions for Agile

David Anderson talks about the history of Agile, the current status of it and his vision for the future. The role of Agile consists in finding ways to implement its principles.

Nick Sieger on JRuby

Nick Sieger talks about the future of JRuby, Java Integration, and his work on JEE deployment tools for Ruby on Rails like Warbler.

Rustan Leino and Mike Barnett on Spec#

Rustan Leino and Mike Barnett of Microsoft Research discuss the technology in Spec# and its futures.

10 Ways to Screw Up with Scrum and XP

Henrik Kniberg talks about 10 possible reasons to fail while doing Scrum and XP. Maybe the team does not have a definition of what Done means to them, or they don't know what their velocity is.