Art of Unit Testing

[Noel Rappin]

Disclaimer: I'm not a true XP expert, but I believe in the value of test 
first design....

>         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.

To be more specific, when doing test-first design in the XP way, you don't 
write _all_ the tests before you code.  You write one test, code the 
simplest thing that could possibly work, then write another test.  You 
continue to go back and forth between tests and code, refactoring the code 
mercilessly to keep it simple as you add new tests.  By following this 
method, your code is always a) working, b) as simple as possible.  When 
defects are found, write a test that exposes the defect and fix the code -- 
you'll have a quick guarantee that you haven't broken any other test.

Now, the art of this is, of course, in the exact definitions of "simple", 
"working", and "refactoring", and "test everything".  The goal here is not 
complete testing in the formal sense, but enough testing to give you 
confidence that the code works.  Still, my experience is that you do tend 
to end up with clear, simple, and elegant code using 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?

Happily, using XP and test-first, you don't need to know what the 
requirements will be before you write it.  In fact, the XP processes are 
based on the assumption that you won't know what all the requirements are 
before you start, or that they will change during coding.  The goals of 
test-first are to keep the code in a state where it is easily modified to 
accommodate change and to give you the test suite so that you can make 
changes confident that you haven't broken anything without realizing it.

My experience is that, far from making programing tiresome and irritating, 
test-first literally rekindled my enjoyment of programming, because of the 
constant feedback.  Especially at the beginning of a project, it's nice to 
have feedback that you are moving forward and doing things well, even 
before there is much in the way of visible results.  I've found that 
programming test-first has reduced long debug sessions to about nil, and 
that writing tests is far less tiresome than long debug sessions.

>         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.


Other people have posted examples.  You can also try www.xprogramming.com 
and www.objectmentor.com for some more examples of test-first (not in 
Python, unfortunately).  There's a Yahoo Group for XP that will answer your 
questions as well.

Hope this helps,

Noel

-------------
Noel Rappin, Principal Software Engineer, Internal Development
Openwave <Noel.Rappin at openwave.com>

The contents of this email message do not necessarily reflect the opinions 
or programming practices of Openwave Systems.