Unit test examples

[Cameron Laird]

In article <3E061447.E96E3D90 at engcorp.com>,
Peter Hansen  <peter at engcorp.com> wrote:
>Greg Brunet wrote:
			.
			.
			.
>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

As usual, I applaud Peter's thoughtful and pertinent
explanation.  

While I've been preaching thin GUIs, and the horrendous
cost of attempts to automate GUI testing in the sense of
commercial products, for many year, I do think I should
mention Android <URL: http://wiki.tcl.tk/Android >.. 
Anyone working work GUIs, and commensurately involved
with GUI testing, should at least be aware of Android's
existence and availability.
-- 

Cameron Laird <Cameron at Lairds.com>
Business:  http://www.Phaseit.net
Personal:  http://phaseit.net/claird/home.html