Test Driven Development? You've got to be kidding me...

Still, starting with testing helps so much to create modular design because it forces you to write clear/clean interfaces between them.

My workflow is usually:

  1. Write the tests and design the module/class/whatever in the same time.
  2. Code it. (Repeat)

Although, I rarely write unit tests in TDD; only tests providing a high level design view (Such as functional or integration tests).

My experience is as follows.

1) TDD encourages testing the smallest unit of functionality possible

2) When you are first developing a large piece of functionality from scratch, you often need to upend the entire architecture a few times as you solidify the design. Theses revamps are the type of thing cannot be done incrementally as large number of small changes. And doing design on paper in advance only goes so far. And these architectural revamps are best done early, as they are far easier to do when you have 1000 lines of code than when you have 100000 lines of code.

3) smallest-unit-of-functionality tests generally get throw away in system-wide revamps

4) Therefore, the cost of these high-level revamps is greatly increased if you need to throw away all these tests every time, hindering productivity.

5) Because of that, I write tests afterwards, once i am comfortable the architecture has stabilized.

TDD is an methodology, not a religion. Do what works best for you and the specific project you are working on.

I'll be honest and say the article started with the most inane troll about people who run their own mail servers and have beards, and was quickly changed when I realized people weren't reading beyond that ;-) Clearly my sense of humour needs work!

I appreciate the article may be a little polemic for some tastes, but you know, I have often had my mind changed in this way before. I've read something deliberately somewhat provocative, which enraged me briefly, but got me thinking, and a week later, I realized had gotten me thinking enough that I'd started to come around to a different perspective.

Thanks for the feedback. The next article planned is a detailed discussion of how to retro-fit an automated test-suite to a web-app that doesn't already have one.

Having responded to the tone elsewhere, I’ll respond to the content here :-)

The article presents a straw-man in the form of someone who believes TDD is the One True Way, and then attacks this by suggesting that the purpose of tests is—more or less—to prevent regressions. Given that this is an important thing, and since TDD isn’t really about that, TDD is clearly not the One True Methodology.

Quite honestly, that makes perfect sense to me. Love it or hate it, TDD is a design technique, not a regression prevention technique. Much of TDD is the creation of tests that validate an implementation, not a requirement. Thus, changing the implementation breaks the tests and you have to fix them. In that sense, the tests TDD produces are useful after the fact in the same way that Design By Contract’s contracts are useful after the fact. And if Design By Contract wasn’t somebody’s trade mark, I would honestly say that TDD is a way of practising DBC when you don’t have a language like Eiffel handy.

Is Design By Contract a useful technique? I think so. Is it the only technique to use? No. Are implementation tests the only tests needed in a project? No. Are the useful? Yes. Do they impose a maintenance overhead? Absolutely. Are there other paths to success? Absolutely.

So in summary, if I take the article at its face value of railing against TDD being the ONLY methodology, I agree. It isn’t. It isn’t even the only testing methodology. However, the TDD baby is staying right here while I toss out the fanaticism bath water. I believe that TDD is a useful tool and that one way to think about it is as a form of Design by Contract at the implementation level.