I’m pleased to announce that the getting started guide, conveniently titled “Getting Started With Rails Testing” is now available for download.

It grew to be a bit longer than I originally intended, but I’m very happy with how it turned out. It starts with an empty Rails application and walks through the first couple of feature additions, adding tests for controllers, models, views, and basic security.

Download, read, enjoy, tell all your friends, let me know what you think. And watch this space for the inevitable errata release, and further announcements about the longer book.

I completely agree with this blog post about testing, and I second the observation that there seem to be a lot of Rails programmers out there not testing.

At Pathfinder, we’ve been asked to take over several preexisting projects that have little or no testing. Asking about test experience is a core piece of our Rails interview process, and I’d say that more than half of our interviews over the past year have no testing experience and turned in a code sample with no tests.

I thought the comments were interesting, but basically broke down into a) I don’t know what to test, and b) the test process breaks my flow.

That’s understandable—I think that the groove you get into when you do test-driven development right is a deep one, and you can definitely get into a nice flow with TDD.

But it’s a narrow groove, it’s not hard to have a bad experience. In fact, if you make your test/code run loop too long, you’re almost guaranteed a bad experience. Tests get much harder to write the longer that the code has sat without tests.

Some representative quotes from the comments to that post, with my thoughts:

“I honestly don’t know what and when to test”

It’s a tough issue, especially with a framework like Rails that does so much on it’s own. My feeling is you don’t need to test anything that Rails is doing (in theory, that’s covered by Rails own tests). Everything else in your code, though, is fair game.

“I Feel that testing breaks ‘flow’”

This is not my experience. At least in web programming, I find that the alternative process of write a little bit of code then try and test it in the browser is much more disruptive than getting the code right with tests, then validating in the browser. Obviously, though, I can’t speak to your own flow.

“But I haven’t found any tutorials or resources that adequately break it down for a total beginner”

Hopefully, I’ll have that out to you shortly. Still, this is a problem. Most technical books are too focused on the actual content to cover tests, and test-only tutorials tend to be separated from context. In the interim, can I humbly suggest my Professional Ruby on Rails? I tried to make as many of the examples as possible have tests written first. You might find that helpful.

“If you’re not already doing it, it never seems like you have the time to learn it before you’re back operating smoothly again.”

Yeah, that’s the good-old productivity paradox, where the people who could most benefit from productivity improvements don’t even have the time to learn the improvements. I don’t have an answer for that one yet.

“Because testing right is hard. Because it’s something that might save your bacon one day, but doesn’t give instant gratification like learning a new programming language. Because it just takes so damn long for me to write tests, time that I feel could have been better spent somewhere else afterwards.”

If you’re taking so long to write tests that it’s interfering with your process that much, then you’re probably either trying to test too much, or letting your test/code/test loop get too long. It’s a little counterintuitive, but it really does make a difference—writing shorter tests then quick code to make it pass really does go pretty quickly.

In some ways testing via test-first is hard, especially if you aren’t used to it. It’s hard to get the rhythm of it down, and really learn to trust the process. But when you get there, going test-driven really does speed things up and help break complex problems into simple parts.