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

Thank you for the very helpful comments, suggestions, stories and  
references.  In addition to the resources suggested, I also found this  
article by Peter McBreen on test-driven development with Ruby:

http://www.informit.com/isapi/product_id~%7BBCD66982-AE50-48AE-8677- 
DA8C16CED845%7D/session_id~%7BA9826E73-41ED-44B9-82A0-891FFB42A417%7D/ 
content/index.asp

David Naseby provided this reference:  
http://www.rubygarden.org/ruby?UsingTestUnit.  I also liked the article  
on testing in reverse linked to at the bottom of this page.

Bill Kelly provided this reference to a newly published book:  
http://www.aw.com/catalog/academic/product/ 
1,4096,0321146530,00.html?type=PRE.

"Chris" <[e-mail]> provided very helpful advice, reproduced  
below, on how to get into unit testing and acquiring the testing  
mindset.  The following is what Chris said:

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

Chris also had some more advanced questions about unit testing, which  
were as follows:

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