culann.com

What and how much?

Lots of people, especially lately, have been talking about testing - there are three full sessions at the Lone Star Ruby Conference on testing alone - so it’s pretty easy to find people talking about how to test. In this post, I just want to call your attention to two specific questions: what to test, and how to know when you’re done.

First, what should you be testing? Obviously, any code you write should be tested. Ideally, it’d be tested before you wrote it (TDD), and you wouldn’t write any code that wasn’t covered by your tests (write the simplest code possible to pass the test, then refactor). This means you should not be testing ActiveRecord, or ActionController, or anything else in the Rails framework. Trust me, if something in there breaks (if you’re running on edge, for instance), your tests will let you know. The closest we get to testing that stuff is in asserting that a Blog has_many :posts, and there we’re really testing that our developers (usually me) didn’t foolishly forget to add the has_many declaration to the class.

Secondly, how do you know when you’re done? Well, you’ve got a couple of options here. The first and easiest is to use rake stats to check your code:test ratio and shoot for some arbitrary number. Slightly better is using a coverage tool like rcov, which will give you a line-by-line analysis of what in your code is covered by your tests. Here again, you should shoot for some (slightly less) arbitrary number - at Viget, we like 100%. (Note that I said ’shoot for’. We don’t always hit 100%, but that is always the goal). The next step up is using a mutation tool like heckle, which changes your code to find out what isn’t being tested as well as it should be. It’s up to you, but pick something and stay with it - and try to move up to the next level when you find yourself comfortable with what you started with.

Whatever you do, keep testing! Testability is a virtue, but only inasmuch as you take advantage of it by ultimately writing and using the tests.