Introducing Unit Testing
withDUnit

DUnit is a
framework of classes designed to support the Xtreme approach to software
testing. It supports Delphi 4 and later.

The idea is that, as you develop or change code, you develop
appropriate verification tests at the same time, rather than
postponing them to a later test phase. By keeping the tests
up-to-date and re-applying them at regular intervals, it becomes
easier to produce reliable code, and to be confident that
alterations (and refactorings) do not break existing code.
Applications become self-testing.

DUnit
supplies classes that make it easy to organize and run these
tests. DUnit
provides two options for running the tests:

As a GUI application, which allows easy selection of individual
tests and groups of tests,

As a console application.

DUnit was
originally inspired on the JUnit framework, designed by Kent Beck
and Erich Gamma for the Java language, but the framework has
already evolved into a more powerful tool, very specific to
Delphi programming. The original Delphi port was done by Juanco Añez, and
the framework is now maintained by the DUnit Group at SourceForge.

Archive contents

The DUnit
distribution archive should be expanded into a directory of its
own in a way so that its directory structure is preserved:

The framework directory contains
precompiled versions of the above framework units, as well as a
Delphi .DCP package definition file that can be used to link the
library as a package (the corresponding .BPL file is in the
bin directory).

Getting started

To write programs that use DUnit, either the source code or the
precompiled framework directories should be included in your unit
search path. You can do this by selecting Tools |
Environment Options | Library in the Delphi IDE,
and adding the DUnit path to the list of paths shown. For example:

Alternatively, you can add the DUnit path to the default project options, or
to a specific project's options by selecting Project
| Options in the IDE:

Your first testing project

Create a new application, and close the
Unit1.pas that Delphi automatically generates you
without saving it. Save the new project (in 'real life' placed in
the same directory as the application that you wish to test)
giving it a name like Project1Test.dpr.

Create a new (formless) unit with File | New |
Unit. This is the file that will contain the test
cases, so save it as something like Project1TestCases. In the
interface uses clause, add a reference to TestFramework.

Declare a class TTestCaseFirst derived
from TTestCase, and
implement a single method TestFirst as
shown below (obviously this is a very diddy example to get you
going). Note the initialization section at the bottom, which
registers the TTestCaseFirst class with
the DUnit
framework.

The results that are to be tested are placed in calls to the
Check method. Here I am unimaginatively
confirming that 1 + 1 is 2. The
TestFramework.RegisterTestprocedure
registers the given test in the frameworks test registration
system.

Now, before running the project, select the Project | View Source menu option to open the
project's source. Add TestFrameWork
and
GUITestRunner to the uses clause. Remove the
default Application code, and replace it with the code shown
below:

Now try running the program. If all goes well, you should see the
DUnit GUI,
complete with a tree display showing available tests (currently
only TestFirst). Clicking the
Run button runs the test. The GUI also allows you to enable
and disable parts of the test hierarchy by clicking on
checkboxes, and has extra buttons for conveniently selecting and
deselecting tests, and complete branches.

To add further tests, simply create new test methods in TTestCaseFirst. The TTestCase.Suite
class method uses RTTI (RunTime Type Information) to find them
and call them automatically, provided the methods meet these two
conditions:

Test methods are parameter-less procedures.

Test methods are declared published.

Note that DUnit builds a separate instance of the class for
each method that it finds, so test methods cannot share instance
data.

To add two more tests, TestSecond and
TestThird, declare the methods like
this:

If you rerun the program, you will see that
TestSecond fails (it has small magenta box next to
it), and TestThird threw an exception
(the box next to it is red). If any tests had succeeded their
boxes would have been green. Tests that are not run bear gray
boxes. The list of failed tests is reported in the pane bellow,
and the details for each of them can be seen in the bottom pane
when they are clicked.

If you are running the program from within the IDE, you may find
that the program halts when you hit an exception. This is
probably not the behavior that you want while using DUnit. You can
disable breaking on exceptions using the
Tools | Debugger Options | Language Exceptions
dialog, and un-checking the "Stop on Delphi
Exceptions" option.

SetUp and TearDown

One often needs to do some common preparation before running a
group of tests, and some tidying up afterwards. For example, when
testing a class, you might want to create an instance of that
class, run some checks on it, and finally free it. If you have a
lot of tests to make, you'll end up with repetitive code in each
test method. DUnit provides support for these situations through
the
TTestCase virtual methods SetUp and
TearDown, which are called, respectively,
before and after each test method is executed. In Xtreme testing
jargon, a prerequisite state like the one provided by these two
methods is known as a fixture.

The following example extends
TTestCaseFirst to do a couple of tests on the
Delphi collection class TStringList:

Test suites

When testing a non-trivial application, you will want to create
more than one class derived from TTestCase. To add
these as top-level nodes, you can simply register them in
initialization clauses, as was shown in the above example. Other
times, you may want to give more structure to your set of test
cases. For this purpose, DUnit supports the creation of test suites,
which are tests that can contain other tests, including other
test suites (it is an application of the Composite design
pattern).

As it stands in the TTestCaseFirst test
case, the SetUp and TearDown methods are called uselessly when
the arithmetic testing methods run. The two methods that deal
with string lists would be better if separated into their own
test case. To do this, start by pulling apart
TTestCaseFirst into two classes, TTestArithmetic and
TTestStringlist:

Other Features

Running Tests in Console Mode

Sometimes it is quite useful to be able run our test suites in a
console window, like when running them from within a Makefile. To
run tests in console mode, create a DPR file that uses
TextTestRunner instead of
GUITestRunner, and add the compiler directive
{$APPTYPE CONSOLE}to the project
file, or selectProject | Options | Linker |
Generate console appliationoption in the
IDE.

To run the example developed above as a console app, create
Project1TestConsole.dpr as follows:

Notice the string '..F.E..'. Here the
framework has printed out a period for each test passed
successfully, an 'F' for tests that failed, and an 'E' for tests
that raised an exception.

You can make the
TextTestRunner halt the program with a non-zero
exit code when failures are encountered by passing a parameter
with value
rxbHaltOnFailures, like this:

TextTestRunner.RunRegisteredTests(rxbHaltOnFailures);

Halting with a non-zero exit code becomes very useful when
running test suites from within a Makefile.

Extensions

The TextExtensions
unit contains classes that extend the functionality of the DUnit
framework. Most of the classes use the decorator pattern,
as defined in the GoF (Gang of Four) "Patterns of Software
Design" book.

TRepeatedTest

TRepeatedTest allows you to repeat the
decorated test a number of times. For example, to repeat the
TestFirst test case of
TTestArithmetic 10 times, you could write the
following code:

TTestSetup

TTestSetup can be used when you wish to set up
state exactly once for a test case class (the
SetUp and TearDown
methods are called once for each test method). For example, if
you were writing a suite of tests to exercise some database code,
you might subclass TTestSetup and
use it to open and close the database before executing the suite.