This article was published in the Borland Community web site on November 29, 1999

Xtreme testing for Delphi programs

A standard testing framework for Delphi has been long overdue. Now there is one and it's even open source.

In my article on Xtreme testing, I talked about how it could improve the quality of programs as well as the speed and confidence with which they were developed. For the examples, I used Kent Beck and Erich Gamma's JUnit open-source testing framework and I wrote the program fragments using Java -- a language I'm comfortable with. But those who know me from previous writing gigs or my once-frequent postings in online forums know that I've long been a Borland Pascal programmer. My online buddies are probably wondering why I didn't write the examples in Object Pascal. The reason is that I discovered Xtreme testing only recently, and, as far as I know, there are no testing frameworks available for Delphi.

But we're about to change that.

I've been choosing the latest version of Borland's Pascal as the best solution to most of my programming needs for 15 years now. The reasons are varied. The tool's suitability to the kind of applications I've been developing is one reason. Its overall quality is another. Not to mention its blazing instant-feedback speed. A large reason has been the community of developers that has gathered around the tool.

I met that community when I joined CompuServe and the BPASCAL forum back in 1993. BPASCAL quickly became an invaluable asset. The forum was filled with excellent questions, prompt answers, expert advice, and loads of useful source code. Examples, workarounds, patches, libraries, frameworks, and even complete applications were available for download and free use. The forum's motto was "Don't pay back -- pay forward," and these guys took it seriously. I started contributing advice and source code as soon as I was confident enough to do so, and eventually became expert enough to start writing about Delphi for trade publications -- but that's another story.

Even after all these years I have never felt that I had managed to fully pay back -- er, forward -- all the help. That's the reason for this contribution: DUnit, a port of the JUnit Xtreme testing framework to Delphi.

Porting from JUnit

The original JUnit framework is extremely easy to use and very effective. I wanted the Delphi port to be as good.

To speed up the port, I decided to translate the classes and interfaces in JUnit almost literally. It was a compromise that required heavy use of method overloading, which means that DUnit won't be usable with versions of Delphi prior to version 4.

I made another compromise. I could translate the methods in JUnit almost literally if I used the Delphi port of the Java collections library that I had begun implementing, so that's exactly what I did.

These two decisions let me do the port in a single afternoon and resulted in a framework that I find very easy to use. But the implementation relies heavily on interfaces and iterators -- idioms seldom used by Delphi programmers. Although the first idiom is fully supported by Delphi, most programmers reserve it for dealing with COM and ActiveX objects. Interfaces provide the advantage of memory management by reference counting, so a little work up-front with interfaces translates into much less code to write. You do have to be careful with some interface implementation issues. For example, a loop with references to interfaces will make it impossible for Delphi to reclaim the memory used.

The second idiom is common in Java and C++ programs, but may be unfamiliar to Delphi programmers. Iterators enable you to write implementation-independent loops that process the objects contained in a collection. JUnit uses iterators, so DUnit does too.

Classes that test classes

To apply DUnit to your Delphi programs, you write a descendant of the class TTestCase for each test case you want to apply to a unit. I decided to apply DUnit to the collections library used in its own implementation. To avoid circular unit references, I had to declare the test case classes in the main program (DPR) file, but I recommend that in general you place the test classes inside the units they test. Doing so will let you test protected and private methods in addition to the public and published ones.

This is the class declaration for a simple test case:

type
  TListTests = class(TTestCase, ITest)
  published
     // published, so we get RTTI;
     // virtual, so the compiler 
     // doesn't eliminate them;
     procedure testEmptyArrayList; virtual;
     procedure testEmptyLinkedList; virtual;
     procedure doEmptyTests(list :IList);
     procedure testFailure; virtual;
     procedure testError; virtual;
end;

The first two methods test several conditions on arrays and linked lists. The third procedure is a utility used by the preceding routines. The last two methods generate a test failure and an exception respectively, to make sure DUnit responds properly when errors are detected. The test methods must be declared within a published section so that Delphi generates runtime type information for them and DUnit has access to method names at runtime. Here's part of the implementation of doEmptyTests:

procedure TListTests.doEmptyTests
 (list: IList);
var
  i :IIterator;
begin
  assert('isEmpty', list.isEmpty);
  assertEquals('size', 0, list.size);
  assert('iterator at end', 
    not list.iterator.hasNext);
  list.add('anItem');
  assertEquals('size', 1, list.size);
  //code>