First up on the Testing Practices Interview series is Geoffrey Grosenbach, Senior Visionary of Topfunky, and also the person behind PeepCode. Geoffrey blogs at http://nubyonrails.com/, and is responsible for the gruff graph generator and, most recently, a task tracker based on David Seah’s Online CEO. He was also kind enough to write his responses in Textile, which I heartily endorse. Take it away…

How did you get into writing tests regularly? Did you have a specific moment when you realized automated testing was valuable?

I remember watching tests run during installation back when I was using Perl (wouldn’t that be nice if RubyGems optionally ran their test suite during installation?). But it seemed like an advanced topic that only some programmers did.

When I started using Ruby and met the testing fanatics at Seattle.rb, I started to understand what it was about and why I might want to write a test.

Three things helped me get started with test-driven development:

• Watching other people do it.
• Writing a graphics library (gruff). I needed to generate a bunch of samples with various data inputs and Test::Unit was a great way to do it.
• Finally, I started out by writing a single test for an existing Rails app whenever I encountered a bug. It gave me peace of mind.

Since then, I’ve appreciated the process of thinking that I get into when I code test-first.

What is your Rails testing process? What kinds of tests do you write, and what tools do you use to write them?

I’ve tried several libraries and tools.

I started with Test::Unit and still use it on some existing projects.

For a while I used Jay Fields’ Unit-Record style of separating out unit and functional tests for both models and controllers (see also). It also provided a nice test method that took a string and a block of assertions (similar to what’s in Rails now).

I’ve used RSpec’s ability to add should syntax into Test::Unit.

I’m currently happy with straightforward RSpec. I also have some Test::Unit integration tests in my Rails apps but have also used RSpec User Stories and their replacement, Cucumber. Given the fact that I’m both the designer and coder of most of my apps, I don’t get much benefit from Cucumber. But I can see how it would be useful to people working for a semi-technical client.

Honestly, it’s a bit overwhelming with all the options out there!

When I’m actually coding, I’ll use Eric Hodel’s ubiquitous autotest or rstakeout to run my test suite.

What’s the most interesting thing you’ve discovered about testing recently?

I’ve been working on a small command-line Objective-C app and am experimenting with using Ruby to run a suite against the command-line app to check the inputs and outputs. Ruby is useful that way and works better for me than trying to use Objective-C for the same purpose.

Is there a tool you wish you had for testing, but which you don’t think currently exists?

I can’t think of one. Usually I end up writing a tool if I need it and I can’t find it anywhere, such as test_benchmark to show individual test runtimes for Test::Unit. Someone recently imported it to GitHub as well.

What advice would you give somebody looking to write more effective tests?

Find a mentor. Work with someone else who is doing it. Concentrate on testing the effects of your code, not the way they are implemented. It’s easy to write tests that really don’t do anything and won’t reveal meaningful changes in the code if it stops behaving properly.