For me, the first point above is the most important: TDD improves interfaces and design.

I agree with this.

What I find disconcerting is that many when they hear TDD and dismiss it never get around to writing proper tests at all. To me, that's an absolute shame (s/ (shame)/insert_bad_word $1/). Not following TDD != don't write any tests.

For example, I know of a company with a very large software suite, and it pisses me off to no end that bugs are frequently found that should have easily been caught if even a few basic tests had of been written. I mean, you have a feature in your software for many years then suddenly it breaks when one is doing a deployment? Give me a break.

I do TDD most of the time, but not all of the time. That doesn't mean one shouldn't write tests at all... it just means its much more unlikely that anyone will get around to it going forward. Personally, 100% coverage is my objective, from several different angles. Either specific existing tests (possibly having been updated or added to) are run before a commit, or if required the whole suite passes first.

Whether one does TDD or not, never neglect a good quality test suite. It doesn't matter if the project is late. On a complex project, would you rather have data inconsistencies in client data down the road because of your neglect, or have the project behind a couple weeks up front because you're validating your code before or as you write it?

update: This kind of sounded like I'm reflecting on you, eyepopslikeamosquito, but it surely wasn't. It's a global thing ;)

I am going to provide a real-world example of why tests are very important, based on a situation I ran into today.

I wanted to make some changes to my XS-based Bit::Manip distribution. One of my goals was to replace calls to stdint.h's pow() function with bit shift operations instead, to remove the reliance on the external library.

With my full test suite in place, I could freely replace things like:

#define MULT 2
return ((int)pow(MULT, bits) - 1) << lsb;
[download]

With:

return ((1 << bits) - 1) << lsb;
[download]

...and not have to worry about a thing, because all I had to do was make the change, run the tests, and on fail, go back to the math. Once all tests passed, I knew I was good.

Without a test suite, how would I ever know if I'm 100% accurate in my modification? I wouldn't be. Because all of my subs are covered entirely, I know that one change there didn't break anything within the sub its defined in, nor does the change break anything far away either.

Hi there. Unwittingly, you have provided perhaps the perfect counter-example to TDD.

Similar to how one cannot prove non-existence, one also cannot anticipate the unforeseeable. In other words, tests may guard against regressions, but they cannot save you from bugs.

In C, bitwise shifts by less than operand width, are allowed. Given 32-bit unsigned int, a shift by 32 invokes undefined behavior. And in particular, on x86 this shift is equivalent to a NOP.

print bit_mask(32, 0);

But don't feel too bad about it; similar shift-mask bugs have occurred in security-critical contexts before...

Interesting .. the last time I used TDD for a big project was for an API that I was developing, and the key (for me, anyway) was that the interface had to be rock-solid -- so, while doing that project, your first point was the most important one to me. The second point is the next most important for me .. having a safety net for when I update something over here .. which ends up breaking something over there. How the heck did that happen? Ah .. git diff to the rescue. How did I miss that? OK, one more test. :)

Your last point, about psychological backup .. it's wonderful to spend some time on the code, and get into the rhythm of running the tests, getting a green result, and doing a commit. The module grows before your eyes, and everything is completely tested.

Great post, thanks so much!

I have found Improved interfaces and design. Especially beneficial when writing new code… completely, shockingly true as well. It is an assumption and sloppy thinking disruptor. It alone comes close to justifying all the costs.