[DUG] Unit Testing

[Leigh Wanstead]

Further to Samuel's post, I usually use interface instead of real Delphi
class. This way I will be able to substitue test class instead of real child
class. The test class just implement interface and offer dummy test code I
wish to test. The whole delphi application does not need to be an active
control server application.

Regards
Leigh

-----Original Message-----
From: delphi-bounces at ns3.123.co.nz
[mailto:delphi-bounces at ns3.123.co.nz]On Behalf Of Allan, Samuel
Sent: Wednesday, 15 June 2005 6:22 p.m.
To: NZ Borland Developers Group - Delphi List
Subject: RE: [DUG] Unit Testing


Re: Shower Testing

You are advocating an approach similar to the one I have taken. I am
assessing a student's academic record against the regulations governing
their programme of study.

The most complex type of rule is a composite of three different
strategies and another composite object. Each of these component classes
has a set of unit tests. At the bottom level, these classes are very
simple and consequently so are their tests.

When I am testing the rule class I construct it using mock component
classes, which behave how I tell them to, and took all of ten minutes to
write. The tests for the rule class simply check that the logic in the
rule class is correctly looking at it's components, which I can tell,
because the mock components are doing as I say.

Sometimes the rule's logic is sufficiently complicated to make this
impractical via it's public interface. I have created test descendent
rule classes that redeclare the protected methods which make up the
logic as public. I then test them, then check that the public methods
are calling them correctly.

This seems to have worked well for me, and I have yet to find out I have
caused myself problems with this approach.

Samuel Allan

_______________________________________________
Delphi mailing list
Delphi at ns3.123.co.nz
http://ns3.123.co.nz/mailman/listinfo/delphi