The Kent Beck book Test Driven Development: By Example explains this in
great detail (and uses Python and Java for code examples.)
Peter
···
-----Original Message-----
From: John Johnson [mailto:jj5412@earthlink.net]
Sent: Monday, June 02, 2003 7:24 AM
To: ruby-talk@ruby-lang.org
Subject: How to structure a program for unit testing
The time has come. I’m tired of that unsure feeling when I’m about to
release a program. So I’ve decided to jump on the unit testing band-wagon.
Trouble is, the wagon is going a little fast for me, and I’m kinda’ hanging
off the back end of it.
My Ruby programs seem to be one monolithic source file (~500 lines or so).
With classes defined, global functions, and, uhm, a global variable or two.
Problem is, I have functions that do a whole lot. They might open a file or
two, massage the data, and put it back into another file.
Is it possible to devise unit tests for programs structured like this?
Should I break my program into more source files? Should I have a lot of
smaller functions that do what the large function does? This seems more
susceptible to bugs, since you’re throwing more data around between
functions. When doing tests on file massagers, do you have a set of input
files that you use for the tests, and that remain with the tests, ie.
TC_Massager would use tc_label.txt and tc_format.txt? Is it okay that the
unit test functions are so closely coupled to the classes, methods, etc.?
(It would seem so, since everyone is so gaga over it
:-))
Thanks in advance, your brillantnesses, I know this is a lot to ask. Feel
free to tell me to RTFM, just provide a link to it 
–
Regards,
JJ
Finally using a Mac!