Art of Unit Testing

[Alex Martelli]

"Jesse W" <jessw at loop.com> wrote in message
news:mailman.998013446.19337.python-list at python.org...
    ...
> resolve.  My doubts lie with the thought that it is very difficult to
> figure out what the requirements of a program will be before you
> write the program,

Which is why, ideally, you have the customer as part of the
development team -- like all XP practices, this is mutually
reinforcing with the others.  The customer's role in the team
is first of all to define the "stories" that the program will have
to meet -- the acceptance tests.  This can't be done ahead of
time -- which is why the customer must ideally be _part_ of
the team, refining and changing the stories as he or she gains
a better understanding of what, exactly, are the business needs.
(Also, as the developers make and refine estimates of how much
work it will be to meet the requirements of each story, the
customer must make the business decision of _prioritizing_,
iteration by iteration -- only the customer can weigh the real
business relevance of various objectives versus the developers'
updated estimates of their costs).

Part of the motivation for XP and other lightweight, adaptive,
iterative approaches is exactly that the classic "waterfall"
model, where it's assumed that all the requirements are to
be determined before design, and all design accomplished
before coding, etc, is such a bad match for the reality of most
software development projects.  But if developers are in a
vacuum, with no real feeling for what business value the
system is supposed to deliver, and no rich continuing feedback
from the customer, on what basis would they adjust the
requirements iteratively?  There HAS to be customer involvement,
one way or another.  "Release early, release often" may be one
way, but you need highly responsive customers for that, too.

If you as the developer are going to be your own customer,
you can do it, as long as you manage to "switch hats" to the
different roles.

> and will this method make programming into a
> tiresome, irritating task, even if I can write these bigger programs?

On the contrary, it seems to me.  Methodologies geared on your
producing lots of paperwork seem much more tiresome and
irritating than ones where the key deliverables are running code
(including tests), particularly if the heavyweight ones don't work:-).

> My question to you all is this:  Do you have any suggestions on
> how to deal with learning to use unit testing in this way, or examples
> of setting up games with this kind of unit testing, or GUI programs?

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.


Alex