Re: Unit Testing in Ruby for the (Absolute) Novice

----- Original Message -----
From: "David Naseby" <[e-mail]>

Go to http://www.rubygarden.org/ruby?UsingTestUnit

Its an excellent intro to the world of test-first development, and unit
testing in Ruby.

David.
----------------------------

Amen.  That site helped me quite a bit.

I also am new to unit testing, and am struggling to figure out where to
start.  My first introduction was in The Pragmatic Programmer (which I
bought because I liked the pickaxe book so much, and I thought it was *at
least* as good... get it!), which convinced me that unit testing was
certainly a good idea.  Yep, I should definitely do that.  No question about
it.  But, uh... what do I do??

Whenever I would think about unit testing (which, I'm pretty sure, is rarely
if ever done in the gaming industry, which I am coming to believe has the
*worst* software practices around), I would think, "Oh, yes, it's a great
thing, but this project is really an exception... games are just too complex
for something like that.  Everything needs to interact with everything
else... (how young I was then (last year)...)"

Then I thought I would try unit testing on some personal projects (as I was
learning Ruby, actually), but again, it just didn't seem like it would work
with this particular project... certainly this isn't the sort of program the
Pragmatic Programmers were thinking of!

At this point, of course, I was starting to think that these were probably
all perfect cases for testing, but that I just didn't know how to do it.
(Hey, I was inexperienced, but I wasn't stupid.)  The problem was, I
couldn't think of how you would unit test unless you used totally contrived
examples... examples made specifically to show unit testing...

What I didn't see was that *that is exactly what you want*!  You want to
turn your code into 'contrived examples' of testable code!  No, that
lightbulb didn't really click until several years later (only about a month
ago).

The best advice for getting your own personal lightbulb to click on:  write
your tests first.  Just a few small ones, nothing elaborate.  Instead of
coding to get the job done, try testing to see if the job *is* done, and
then *just* code to satisfy your tests.  (Memorize that last sentence; it
has become my mantra.)  That's the hard part for me:  keeping my head up
when I write my tests, and my head down when I write the "real" code.

My post-lightbulb realization:  You can't ****ing unit test if you don't
have any ****ing units!  I really think that was my biggest problem:  the
non-modular code I was starting with.  My solution, like I said, was to
start with *no* code.  It really made a huge difference in my ability to see
where I should go.

There are still plenty of things I don't know about it, though:

- How to test GUIs, for example?  (Well, if the code is modular enough, you
can test everything but the GUI, which itself probably won't be such a
source of bugs...)

- How does writing your unit tests first relate to rapid prototyping?  How
deep does one write one's initial tests?  Is it better to test at the higher
levels first, using mock objects to work on, then go ahead and code that
higher level (which seems to be what rapid prototyping would suggest I do)?
Or should I keep trying to write all of my tests first (that being the bulk
of the design of the project(?)), then just satisfy my tests right at the
end?  (I guess it seems like the right way to test, but it doesn't seem like
you prototype anything this way.)

- Is there a good description of using mock objects anywhere?  It sounds
nice, but there's nowhere in my brain for it to click into, yet.

Chris