Art of Unit Testing

[Cameron Laird]

In article <9lig4u0r55 at enews3.newsguy.com>,
Alex Martelli <aleaxit at yahoo.com> wrote:
			.
		[much else true]
			.
			.
>Unit tests that are not automated have modest value.  Fortunately,
>the *units* (components) CAN be tested with test harnesses that
>don't actually draw to the screen nor wait for joystick input (etc)
>but rather simulate those activities to check the logic of the various
>components, producing textual output that can be checked by the
>usual means.  The *acceptance* test (the customer's stories) may
>be a different issue -- we've had some modest success with a
>"capture and playback" approach, but that requires a "mock system"
>be running to do your "capturing" in the first place, and there are
>lots of uncertainties on how to keep the C&P test suites useful when
>the GUI's layout and logic change.
			.
			.
			.
I'll selectively reinforce Alex's many points:
C&P can be *quite* modest in its return, it has
LOTS of uncertainties with even the slightest
change in font/display resolution/host/graphics
drivers/layout/..., and yet, GUI systems *can*
be designed for testability
<URL: http://www.itworld.com/AppDev/1243/UIR010323testinggui2/ >
-- 

Cameron Laird <claird at NeoSoft.com>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html