Random Thoughts about Adopting TDD
There are plenty of folk who have realized that test-driven development is an amazing way to deliver better code faster. One of the claims I hear from a lot of places is that you should strive to unit test everything. Unit tests are fast and small and super reliable, and we all want that, right?
Sure do, but if you are trying to testify an existing project, it’s going to be really bloody hard to get to the point where you can write real unit tests at all, and they are by no means the only kinds of tests you’ll want anyway.
Adopting TDD in an existing project, with an existing team is generally very difficult not only because you have to acclimate your company culture, but because whatever code you’ve got is not written test-first.
Instead of going whole hog on pure unit tests, you can get a huge part of the benefit at a fraction of the cost simply by sucking up the speed hit (and reliability) by writing functional tests instead. In a desktop game, that may mean constructing the entire app and prodding it with windows messages. On the server, you might just want to try setting up engineer workstations as tiny production-clones and allowing your tests to connect to an actual database.
Whatever the application, figuring out this bit of technology gives you what you need to instate what I consider to be the first important engineering policy that will turn your company culture the right way: wherever possible, bugs should not be considered to be fixed until they have regression tests. Acceptance tests are easy to intuitively grasp, so it should be relatively easy to eliminate repeat bugs this way.
Further, this approach saves you some momentum in the short run: figuring out how to write code that can be unit tested is hard and will take some time. Bugfixes are perfect targets for this effort simply because the feature already broke. Instead of (well, in addition to, I suppose) committing to abstract pontification about what kind of tests you need for some new feature that customers have never seen, you have a certifiable, concrete weakness in your software. All you have to do is write a tiny program that asserts that it no longer exists.
If you can nail this, you have gotten your foot in the proverbial door. You will probably have gnarly, unreliable tests that are a pain to deal with for awhile, but you have them, which puts you in a position of learning how to make them better.