Unit Testing in Ruby for the (Absolute) Novice

ruby-talk
1

I am new to Ruby and to programming. One thing I like about Ruby is
that one very quickly starts thinking about object-oriented programming
concepts and practices. Most of these concepts are quite difficult to
learn, but one can see the beginnings of the path ahead fairly easily.
For example, objects, classes, methods, UML, patterns, uses cases, CRC
cards, and so on, are all difficult and can be thought about and or
studied for years, but one can learn what they are about fairly quickly.

If only this were true for me for unit testing. I have looked around
and read a little, not all of it helpful. I have formulated the
following ideas about unit testing: (1) unit testing is good; (2) it is
a good idea to write unit tests before coding a class; (3) uh . . . .

This leads to me to many questions: (1) how do you write a unit test?;
(2) uh . . . .

The following example may not need unit testing in the real world, but
is shown to show that I have thought about the problem a little and to
show that my understanding of Ruby is somewhat superficial (for
example, I have trouble following examples that talk about foo and bar).

class Link
methods: initialize, send_url
attributes: name, location, description

[unit tests go here? before the coding? what are assertions? what I am
supposed to assert? what should go here?]

code:

class Link
def initialize(n, l, d)
@name = n
@location = l
@description = d
end
def send_url
puts @location
end
end

Any comments, suggestions, references to other resources, thoughts,
teaching, etc. would be very welcome.

2

I am new to Ruby and to programming. One thing I like about Ruby is that
one very quickly starts thinking about object-oriented programming
concepts and practices. Most of these concepts are quite difficult to
learn, but one can see the beginnings of the path ahead fairly
easily. For example, objects, classes, methods, UML, patterns, uses
cases, CRC cards, and so on, are all difficult and can be thought about
and or studied for years, but one can learn what they are about fairly
quickly.

If only this were true for me for unit testing. I have looked around and
read a little, not all of it helpful. I have formulated the following
ideas about unit testing: (1) unit testing is good; (2) it is a good idea
to write unit tests before coding a class; (3) uh . . . .

This leads to me to many questions: (1) how do you write a unit test?; (2)
uh . . . .

[lots of good stuff snipped here]

Any comments, suggestions, references to other resources, thoughts,
teaching, etc. would be very welcome.

I second this request! I have a vague concept of what Unit Testing is, but
I don’t really understand how or when to apply it. What are some good
starting points for studying something like this? Books? Web sites? How do
you test a GUI? and … and …

This would be good enough information that it could probably go up on the
rubygarden Wiki, too. There are a few ragged starting points in there, but
not much for the person who really doesn’t know about testing.

Thanks,

  • Brian W

Brian Wisti
brian@coolnamehere.com
http://coolnamehere.com/

···

At 12:44 PM 11/25/2002 +0900, you wrote:

3

Any comments, suggestions, references to other resources,
thoughts, teaching, etc. would be very welcome.

A book on Test-Driven Development was just published:
http://www.aw.com/catalog/academic/product/1,4096,0321146530,00.html?type=PRE

(The code examples contained therein, however, are Java, not
Ruby…)

Regards,

Bill

4

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~{BCD66982-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” nemo@hellotree.com 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."