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!