CLUnit - A Unit Test Tool for Common Lisp

CLUnit is a tool that allows Common Lisp users to define and run unit tests. Although similar in purpose to the venerable RT, we believe that CLUnit can not only specify more powerful types of tests, but that it is also much simpler to use. In addition, CLUnit was designed to be used in an environment characterized by frequent interactive unit test runs.

CLUnit is written in ANSI Common Lisp. It has been tested (so far) under Franz Allegro, Xanalys LispWorks, CMUCL, CLISP, and Corman Lisp. CLUnit is available for general use under the LGPL. It is provided as part of CLOCC. In additon, it can be downloaded here (look in the attachments).

History

While looking into eXtreme Programming (XP), an agile methodology for developing software, I started to wonder whether or not this methodology would be suiatble for development in Common Lisp. Although many of the code level practices of XP are similar in philosophy to interactive programming in general, XP places heavy reliance on unit testing. In XP, unit tests are designed for each piece of functionality and the tests are run continually, showing immediately any regression in code functionality or stability. In order to do this, XP'ers have built various testbeds that they use to define and run tests (for example, JUnit, PyUnit, SUnit, etc.).

There has been at least one other unit test tool written for Common Lisp: RT; but this system has at least two drawbacks that make it unsuitable for use in a highly interactive environment. First, RT drops into a debugger whenever a test fails. In XP, unit tests are run continually. If the test system entered a debugger each time a unit test failed, the pace of work would slow to a crawl. Even though one must eventually handle all unit test failures, one must be able to choose when to deal with these failures. RT is problematic because it does not give users this choice. The second issue is less problematic, though equally annoying: RT's definition of a test is simply a function that returns true if the test succeeds and nil if it fails. Although this definition is very general, it does not provide much power to the programmer when writing tests, making them more unweildly, more error prone, and less maintainable.

Because I had tried using RT and had found it less than suitable for my purposes, I developed CLUnit. CLUnit provides relief from both of the issues noted above. By wrapping test execution within error handling code, CLUnit can report failed tests without throwing the user into the debugger, allowing the user to handle unit test failures when it is more convenient for him. CLUnit also provides a hardier test definition system, allowing the user to define complex tests in a modular manner.

I've used CLUnit in developing an optimization framework and as a basis of research for a project in small-scale use of XP. It seems to work pretty well for me!