[DUG] Unit Testing

[David Brennan]

I would also be interested in hearing a lot more about how people use Unit
testing. I haven't researched the subject in much detail but I see some
major problems in using it widely for our applications. 

The core functionality of our software revolves around manipulating large
business objects comprised of many other business objects. For example a
shower has collections of fittings, measurements, panels, etc with many of
these have sub items such as panels which are themselves a collection of
points, edges, clearances, cutouts, etc.

In order to test medium level functions such as say Edge.GetTightGap
(returns the gap between the wall/floor and the glass on a particular edge)
you need to have several helper collections (eg Settings, Fittings,
Clearances) loaded into memory with sensible data. You also need to have a
full shower in memory - a single edge won't work because the real life logic
is that sometimes the clearance tight gap depends on the configuration of
the rest of the shower.

Thus a unit test for Edge.GetTightGap would in fact be using a large part of
our application and populating many objects, either by loading from a static
testing only database (which would still need to be updated to keep up to
date) or by populating with 'fixture' code. 

And then there is the number of tests you would need to run, each of which
would need a different 'fixture' to run. Sometimes the clearance comes from
a fitting (with each fitting having internal code which sometimes handles
special cases), sometimes from a clearance rule, sometimes both (ie the
clearance rule is specified by the fitting), there are half a dozen special
cases which rely on looking at hardware and clearances throughout the rest
of the shower. To cover the permutations a huge number of test cases (ie
showers) would be required.

I believe the 'official' answer to some of this is to build your unit tests
from the ground up, one little part at a time so by the time you reach the
unit test for GetTightGap you already know most of the logic it relies on
works. But even so I think the core question remains. How do you write unit
tests to productively test a function whose behaviour depends heavily on the
existence and makeup of a large and complex data structure in memory?

I look forward to hearing some ideas.

David.

-----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 4:28 p.m.
To: leighw at softtech.co.nz; NZ Borland Developers Group - Delphi List
Subject: [DUG] Unit Testing

...

Also, often the code in the tests is more long-winded than the
application code. But less complicated. Perhaps this is my poor test
writing. And my tests are often more than just one Check(), but given
the amount of setup code... In general, I find most of my test code is
setting up fixtures.