Some argue that it’s best to test while you work, and some argue it’s best to write the test before the method. I kind of disagree with both. For me, testing is an entirely different mindset than writing traditional Rails code. I mean, it’s all Ruby, but it’s different.

I have to be in a “test mode” to write solid tests, even if that means doing it later on in the project. I’m not particularly good at switching back and forth, so I’ll develop a reasonable “chunk” of functionality, and then go back and write a series of tests for that chunk, later.

By separating those two, testing almost becomes addicting in some ways. I love seeing 0 failures, 0 errors, but you’re absolutely right, it’s often not as easy as it seems. I’m still in Test::Unit, which is fine for me (right now). I hear there are better libraries and ways to test, but this is just fine so far.

Good luck with it…

One thing I can add which I wish someone had told me when I’d started with TDD - you can’t do TDD if you don’t know where you’re going. I used to spend a great deal of time trying to figure out how to test first when spiking or prototyping. If you’re exploring an idea or evolving your design in code, but aren’t sure what exactly you’re aiming for, you cannot be expected to test first. Once you’ve got your design fleshed out then you go ahead and write tests for your logic.

One deficiency in Rails testing is the lack of integrated support for functional tests. It helps to start building a functional test suite quite early in your application life-cycle. We usually use either Selenium or Sahi which simulate user interactions with the browser to build these tests.
Funtional tests are usually run in a secondary build (because it can take quite long to run as the number of tests increase) triggered by the first build (the regular rake -t build) passing.

Setting up your build in a CruiseControl.rb instance (it takes under 30s) also helps streamline things a great deal.

But you’re right. Testing isn’t easy, at first. With respect to the decision making overhead, I find writing the tests first help with that. Then you’re not trying to form your specifications around blobs of code that may-or-may not be testable, and instead are writing what you expect right up front.

It does take a whole lot of getting used to, but in practice, I’ve found that to dissolve the ‘how should I be testing this’ problem and move it into “how can I write testable code”. This usually means tiny methods that are easy to poke at when needed. It does result in better code, too.

The problem is, if you’ve got a job with a tight deadline you’re trying to hit, maybe that’s not the time to start learning to make TDD/BDD a common practice. I’ve been in that boat before, and I find that even if you can’t have a comprehensive test suite, it pays off to eventually layer testing in.

The most important places?

• Any bug reports you get, to avoid regressions
• Any business logic that can be expressed clearly in tests
• When you refactor code, add tests for that chunk to make sure you don’t introduce new bugs.

I would have liked to layer in more advice like that into my article, but article length constraints and a pre-specified scope left me little room to talk about the “why?” part.

Anyway… best of luck. Hopefully things will get better over time, as if you’re working in Ruby/Rails you really won’t be comfortable without a strong appreciation for testing. Most jobs sort of expect it, too. :-/