Rails Test Prescriptions Blog

Keeping Your Application Healthy Since 2008

Testing Advice in Eleven Steps

As it happens, my generic advice on Rails testing hasn’t changed substantially, even though the tools I use on a daily basis have.

  • Any testing tool is better than no testing. Okay, that’s glib. You can make an unholy mess in any tool. You can also write valuable tests in any tool. Focus on the valuable part.

  • If you’ve never tested a Rails application before, I still recommend you start with out of the box stuff: Test::Unit, even fixtures. Because it’s simpler and there’s a very good chance you will be able to get help if you need it.

  • That said, if you are coming into a team that already has a house style to use a different tool, use that one. Again, because you’ll be able to get support from those around you.

  • Whatever tool you choose, the important thing is to write a small test, make it pass with a small piece of code, and refactor. Let the code emerge from the tests. If you do that, you are ahead of the game, no matter what tool you are using.

  • At any given moment, the next test has some chance of costing you time in the short term. The problem is it’s nearly impossible to tell which tests will cost the time. Play the odds, write the test. Over the long haul, the chance that the tests are really the bottleneck are, in my experience, quite small.

  • If you start with the out of the box test experience, you will likely experience some pain points as you test more and more. That’s the time to add new tools, like a mock object package, a factory data package, or a context package. Do it when you have a clear sense that the new complexity will bring value.

  • Some people like the RSpec syntax and, for lack of a better word, culture. Others do not. If you are one of the people who doesn’t like it, don’t use it. Well, try it once. You never know.

  • I go back and forth on whether Test::Unit and RSpec are actually functionally equivalent, and eventually have decided it doesn’t matter. You can write a good test suite in either, and if there is a particular bell or whistle on one of them that attracts you or repels you, go that way.

  • You really should do some kind of full-stack testing, especially once you’ve gotten good at unit testing. But whether it’s the Test::Unit integration testing, the new Capybara syntax, or Steak, or Cucumber, is, again, less important than the idea that you are specifying behavior and automatically verifying that the code matches the specification. Most of what I said about RSpec above also applies to Cucumber.

  • This old joke that was repeated with relish on the XP mailing list circa 2000: “Doctor, it hurts when I do this”. “Then don’t do it”.

  • And last, but not least, buy my book. Or buy Dave’s book. Or Kent Beck’s book. Or hang out on mailing lists. Ask questions on Twitter. If you want to get better at testing, there are all kinds of resources available.

Advertisements

2 responses to “Testing Advice in Eleven Steps

  1. yachris March 31, 2011 at 4:51 pm

    “Play the odds, write the test. Over the long haul, the chance that the tests…”

    …will save your butt (and let you avoid a long, painful debug session) rises exponentially.

    Really, any *one* time someone messes something up and the tests catch it *immediately*, so it can be fixed while the whole context is still in one’s brain, more than makes up for the time spent writing the tests.

  2. Pingback: Trevor Turk — Links for 5-17-11

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: