Art of Unit Testing
noel.rappin at openwave.com
Sat Aug 18 04:18:50 CEST 2001
Disclaimer: I'm not a true XP expert, but I believe in the value of test
> 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
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 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.
More information about the Python-list