Access denied | en.bitcoin.it used Cloudflare to restrict access
Please enable cookies.
What happened?
The owner of this website (en.bitcoin.it) has banned your access based on your browser's signature (3d28fb68fce69bb7-ua98).This work is licensed to you under version 2 of the
Alternatively, you may choose to receive this work under any other
license that grants the right to use, copy, modify, and/or distribute
the work, as long as that license imposes the restriction that
derivative works have to grant the same rights and impose the same
restriction. For example, you may choose to receive this work under
License, the XEmacs manual license, or
Please note our .& 1993 - 2017 Easysoft Limited. All rights reserved.
Oracle& is a registered trademark of Oracle& Corporation and/or its affiliates. Other trademarks and registered trademarks appearing
are the property of their respective owners.DUnit - Xtreme testing for Delphi
Xtreme testing for Delphi
by Will Watts
edited by Juanco A&ez
Copyright & 1999 Will Watts. All rights reserved.
Later versions are &
The DUnit Group. All rights
This text may be distributed freely as long as it's reproduced
in its entirety.
A Ttraditional Chinese translation of this document can be found
Introducing Unit Testing
with DUnit
DUnit is a
framework of classes designed to support the
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.
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.
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
the framework is now maintained by the
Archive contents
distribution archive should be expanded into a directory of its
own in a way so that its directory structure is preserved:
Precompiled framework modules
Library source
Help file, home page and MPL license
Home page images
Time2Help generated API documentation
Contributed modules.
A tool for automatically generating test cases
Test cases for the framework itself.
Precompiled, standalone GUI test runner.
Examples of how to invoke DUnit from the command line
collection
A Java-like collections implementation and its DUnit test
registration
Using the test case registration system
Alternative ways to organize tests
Placing test cases in their own units
Placing test cases in the same unit as the tested code
A step by step example of building a registry utility, with
test cases
Shows how to embed the GUITestRunner in another tool's forms.
Test cases for the Delphi Classes.TList object
The src directory contains the
following files:
The framework itself.
Decorator classes that may be used to extend test cases.
Classes for testing user interfaces (Forms and Dialogs).
Routines to run tests in console mode.
The graphical user interface to the framework..
The GUITestRunner Form
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 .
Declare a class TTestCaseFirst derived
from , 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
framework.
unit Project1TestC
TestFrameW
TTestCaseFirst = class(TTestCase)
procedure TestF
implementation
procedure TTestCaseFirst.TestF
Check(1 + 1 = 2, 'Catastrophic arithmetic failure!');
initialization
TestFramework.RegisterTest(TTestCaseFirst.Suite);
The results that are to be tested are placed in calls to the
method. Here I am unimaginatively
confirming that 1 + 1 is 2. The
registers the given test in the frameworks test registration
Now, before running the project, select the Project | View Source menu option to open the
project's source. Add
to the uses clause. Remove the
default Application code, and replace it with the code shown
program Project1T
TestFrameWork,
GUITestRunner,
Project1TestCases in 'Project1TestCases.pas';
{$R *.RES}
Application.I
GUITestRunner.RunRegisteredT
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
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
To add two more tests, TestSecond and
TestThird, declare the methods like
TTestCaseFirst = class(TTestCase)
procedure TestF
procedure TestS
procedure TestT
procedure TTestCaseFirst.TestS
Check(1 + 1 = 3, 'Deliberate failure');
procedure TTestCaseFirst.TestT
Check(1 div i = i, 'Deliberate exception');
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
virtual methods
, 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:
TestFrameWork,
// needed for TStringList
TTestCaseFirst = class(TTestCase)
Fsl : TStringL
procedure SetUp;
procedure TearD
procedure TestF
procedure TestS
procedure TestT
procedure TestPopulateStringL
procedure TestSortStringL
procedure TTestCaseFirst.SetUp;
Fsl := TStringList.C
procedure TTestCaseFirst.TearD
procedure TTestCaseFirst.TestPopulateStringL
Check(Fsl.Count = 0);
for i := 1 to 50 do
// Iterate
Fsl.Add('i');
Check(Fsl.Count = 50);
procedure TTestCaseFirst.TestSortStringL
Check(Fsl.Sorted = False);
Check(Fsl.Count = 0);
Fsl.Add('You');
Fsl.Add('Love');
Fsl.Add('I');
Fsl.Sorted := T
Check(Fsl[2] = 'You');
Check(Fsl[1] = 'Love');
Check(Fsl[0] = 'I');
Test suites
When testing a non-trivial application, you will want to create
more than one class derived from . 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
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:
TTestArithmetic = class(TTestCase)
procedure TestF
procedure TestS
procedure TestT
TTestStringlist = class(TTestCase)
Fsl : TStringL
procedure SetUp;
procedure TearD
procedure TestPopulateStringL
procedure TestSortStringL
(Of course, you should update the method implementations too).
Now, change the unit's initialization code to read as follows:
RegisterTest('Simple suite', TTestArithmetic.Suite);
RegisterTest('Simple suite', TTestStringList.Suite);
Building test suites step by
unit exposes the
class, the class that
implements test suites, so you can create test hierarchies using
more explicit code:
The following function, UnitTests,
creates a test suite and adds the two test classes to it:
function UnitTests: ITestS
ATestSuite: TTestS
ATestSuite := TTestSuite.create('Some trivial tests');
ATestSuite.addTest(TTestArithmetic.Suite);
ATestSuite.addTest(TTestStringlist.Suite);
Result := ATestS
Yet another way to implement the above function would be:
function UnitTests: ITestS
Result := TTestSuite.Create('Some trivial tests',
TTestArithmetic.Suite,
TTestStringlist.Suite
In the above example, the
constructor adds the tests in the passed array to the
You can register a test suite created in any of the above ways by
using the same call you use to register individual test cases:
initialization
RegisterTest('Simple Test', UnitTests);
When run with ,
you will see the new hierarchy.
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
instead of , and add the compiler directive
{$APPTYPE CONSOLE} to the project
file, or select Project | Options | Linker |
Generate console appliation option in the
To run the example developed above as a console app, create
Project1TestConsole.dpr as follows:
{$APPTYPE CONSOLE}
program Project1TestC
TestFrameWork,
TextTestRunner,
Project1TestCases in 'Project1TestCases.pas';
{$R *.RES}
TextTestRunner.RunRegisteredT
When the program is run, the output looks like this:
DUnit: Testing.
Time: 0.20
FAILURES!!!
Test Results:
Failures: 1
There was 1 error:
1) TestThird: EDivByZero: Division by zero
There was 1 failure:
1) TestSecond
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
halt the program with a non-zero
exit code when failures are encountered by passing a parameter
with value , like this:
TextTestRunner.RunRegisteredTests(rxbHaltOnFailures);
Halting with a non-zero exit code becomes very useful when
running test suites from within a Makefile.
Extensions
unit contains classes that extend the functionality of the
framework. Most of the classes use the decorator pattern,
as defined in the GoF (Gang of Four) "Patterns of Software
Design" book.
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:
TestFrameWork,
TestExtensions, // needed for TRepeatedTest
// needed for TStringList
function UnitTests: IT
ATestArithmetic : TTestA
ATestArithmetic := TTestArithmetic.create('TestFirst');
Result := TRepeatedTest.Create(ATestArithmetic, 10);
Notice the constructor for
TTestArithmetic.
ATestArithmetic := TTestArithmetic.create('TestFirst');
Here I have passed in the name of the test method that is to be
repeated. Naturally it must be spelled correctly, or
disappointment will follow shortly thereafter.
If you wanted to test all of the
TTestArithmetic methods repeatedly you can stick
them in a suite:
function UnitTests: IT
Result := TRepeatedTest.Create(ATestArithmetic.Suite, 10);
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
use it to open and close the database before executing the suite.
References
homepage at SourceForge ()
Latest source, mailing lists, FAQs etc
Xtreme testing for Delphi programs ( )
Juancarlo A&ez's introduction to his
DUnit classes, originally
published on the Borland Community website.
JUnit Test Infected: Programmers Love Writing Tests ()
A good article describing JUnit, the Java framework upon which
Simple Smalltalk Testing: With Patterns ()
Kent Beck's original paper. Hard going for non-Smalltalkers.