Home Original page

Unit test examples

Peter Hansen peter at engcorp.com
Sun Dec 22 14:36:39 EST 2002 
Greg Brunet wrote:
> 
> Thanks everyone for the recommendations.  I've downloaded Dive Into
> Python & have started looking at that & I'm trying to get a copy of the
> draft TDDBE.  It's valuable to see how things are done on a small scale
> so that I'm not overwhelmed trying to understand new things, and can
> learn to be more Pythonic in my thinking.
> 
> One thing that I'm wondering about though, is how to handle larger
> systems - especially complex GUI applications.  

The industry is finally beginning (IMHO) to understand this and some 
other areas which have similar properties, one of which is embedded
development. 

The common property they share is that of an external interface which
cannot be automatically tested.  In the case of a GUI it's the interface
with the user, obviously, while for embedded work it's the interface
with some hardware -- possibly as of yet undeveloped hardware.

The current thinking is that one approaches this by developing a
"thin" layer (as mentioned in some other responses you've seen) which
is not test-driven, but which is at least in theory so simplistic 
and decoupled that it does not *need* an extensive net of unit tests
to make it manageable.  You develop this very thin interface the 
traditional way, sort of, which is to say by direct observation that
it "does what you want".  Provided you've made it thin enough, you
may never have to maintain the individual methods, other than perhaps
adding a new one from time to time.

Once you have this thin interface, and have proven that it "works",
and are confident it is simple enough that it always will work, you
can prepare a mock object to substitute for this interface in the
automated testing of the rest of the application.

We've been using this approach successfully, including most recently
within a complex multithreaded system which among other things has
to manage a dialup PPP interface.  We now have a very thin PPP driver
which has four methods, five events, and no memory of state, making
it fairly trivial to test manually.  All the complexity is in an
internal PPP manager object which is fully tested with a mock PPP
driver object.  The worked followed the theoretical TDD approach
for this kind of thing, and I must say it has worked out very well.

-Peter
More information about the Python-list mailing list