Question

I have a Rails project which I neglected to build tests for (for shame!) and the code base has gotten pretty large. A friend of mine said that RSpec was a pain to use unless you use it from the beginning. Is this true? What would make him say that?

So, considering the available tests suites and the fact that the code base is already there, what would be my best course of action for getting this thing testable? Is it really that much different than doing it from the beginning?

Answer 1

This question came up recently on the RSpec mailing list, and the advice we generally gave was:

• Don’t bother trying to retro-fit specs to existing, working, code unless you’re going to change it – it’s exhausting and, unless the code needs to be changed, rather pointless.
• Start writing specs for any changes you make from now on. Bug fixes are an especially good opportunity for this.
• Try to train yourself into the discipline that before you touch the code, first of all write a failing example (=spec) to drive out the change.

You may find that the design of code which wasn’t driven out by code examples or unit tests makes it awkward to write tests or specs for. This is perhaps what your friend was alluding to. You will almost certainly need to learn a few key refactoring techniques to break up dependencies so that you can exercise each class in isolation from your specs. Michael Feathers’ excellent book, Working Effectively With Legacy Code has some great material to help you learn this delicate skill.

I’d also encourage you to use the built-in spec:rcov rake task to generate code coverage stats. It’s extremely rewarding to watch these numbers go up as you start to get your codebase under test.