Jamie, how closely do you adhere to "official" TDD practices, Soren Johnson asks.
Short answer is: not very.
Although I tried to be rigorous at first, putting a test around every function I wrote or every change I made, the number of false positives was disheartening, and I eased off to where I was just testing things that weren't likely to change. I slacked off too far, and some bugs crept in that could have been prevented, and now I've found an equilibrium. And the other coders on the team are less rigorous than I, but I'm not being a fascist about it.
Do we write a test for every bug, at least? Again - no. I haven't figured out a good way to test multithread bugs, for example. I considered a test where we'd spawn the troubled function on two threads - but it would behave unpredictably. A broken function could pass just by luck.
Other TDD 'best practices' we ignore:
- no file I/O - your file I/O should be mocked out, because it's too slow. Bah. It's not that slow - the easiest way to test saving/loading for us is just to save & load and make sure it's the same.
- fast tests - our test suite takes a few minutes to run.
- only one assert per test - whatever. The asserts catch their prey whether they're clumped or not, and we can do less copying-and-pasting this way.
A good book, by the way, on TDD, which Noel Llopis recommended to me, is *Working With Legacy Code*.
My recommendation, if your code is buggier than you'd like (and whose isn't?), is to try it! Be rigorous at first, and then find your sweet spot.
And here's something to think about - although it was "just barely a win" for us - we're a bodaciously small team (one full-time coder, two part-time) writing in a high level language. Not a very bug-prone environment! Lots of coders and designers working together in a mixture of C++ and your-game-scripting-language-here are going to introduce a lot more bugs than we do - making TDD all the more desirable.