Art of Unit Testing

[Peter Milliken]

Well Jesse, might I suggest that the reason you might be in these binds
might lay in the fact that you don't figure what the requirements are before
you code! :-). I haven't (bothered) to read about Extreme Programming -
there is a new buzzword/method every 6-12 months that people flock to hoping
for the proverbial silver bullet for achieving correct software development.
Life is too short to follow all of these fads.

At the end of the day, I have never had any trouble with the standard
approach taught in many software engineering courses i.e. determine the
requirements (which may require some rapid protyping - not all problems can
be well defined up front! :-)), laying down a proper decomposition of the
problem i.e. design and continue the design step until code modules are
easily identified. Then and only then write the code. If you follow these
simple steps, then you can determine (some of) unit test criteria before you
write your code because you have designed what modules are going to be
required! Of course, you won't determine all unit test criteria (only
testing at the interface of the routine level) until you write the code -
since unit test, by definition, involves testing all of the paths through
the code :-)

I have followed this regime for 20+ years of programming now and have never
delivered a flop to the customer. The only time I get into a "bind" is when
I am writing something at a personal level and decide I know enough to go
direct to code - then I get to this stage myself. But retreating backwards
and doing it properly has always solved the issue (and you "relearn" the
value of taking the upfront time to do it properly! :-)).

As for your existing "binds", step back from the code and attempt to
diagram/document the structure of your implementation attempt. Hopefully,
this will show you where your problems lay (usually the pieces just don't
fit together because you didn't decompose them from the top - they grew from
the bottom as individual entities with little or no chance of meeting up
together for a harmonious whole). Producing unit tests for pieces of code
that doesn't fit together will not solve the problem. If you still can't see
the "woods for the trees" then at least you will have something you can show
a friend (who hopefully has enough experience to help you out).

Goodluck,
Peter

"Jesse W" <jessw at loop.com> wrote in message
news:mailman.998013446.19337.python-list at python.org...
> Dear kindly snake people,
> I have read about, and downloaded, some of the Python unit
> testing frameworks available, but I have never yet been able to
> actually use any one of them to implement actual _tests_. I wish to
> use unit tests(at least, the kind of unit tests used in Extreme
> Programming(I think))because one of the claims of aficionados of
> this approach is that it helps them get over the problem of how to
> make programs that can't be kept in mind as a whole. This amazing
> feat is done, say the aficionados, by writing the unit tests out before
> the code.  I have both great hope and significant doubts about this
> method.
> I hope, as I said above, that this method will allow me to finish
> various projects I have started and had to abandon because I got
> stuck in binds I could not specifically understand or find out how to
> 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, and will this method make programming into a
> tiresome, irritating task, even if I can write these bigger programs?
> 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?
> Really, any thoughts or comments you might have about this form of
> unit testing, or how to learn to use it, would be very appreciated.
>
> Thank you all for your time,
> Jesse F. Weinstein
>