Today, automated test builds are a goal of most development shops, and Martin Fowler’s article on Continuous Integration provides an excellent overview about the major aspects. Regardless of where your team is on the path to achieving this goal, here are a few hints how to ease your way.
The committer pulls test coverage out of the team
At the start, your test coverage will be somewhere between nothing and miserable. But, remember, you already have an ace up your sleeve. That’s right, put the "Committer" to work enforcing test coverage for every bug fix and new, complex code changes. Bug fixes are exceptionally interesting code changes. First, they show a place in the code that’s actually used by customers! This is really important information if you know that only about 30% of your code base will really ever get used. Additionally, it makes a lot of sense to write a test for this piece of code (would have made more sense to do it for the initial release, but baby steps to success) as it broke already once. As for complex code changes, I’m talking about things like nested if declarations – these are usually ugly to read (and harder to understand) so why not just enforce test coverage for them.