I don't do TDD all the time, but I used it in a few strategic projects in daytime jobs. I was taught TDD in college by an excellent professor that used a simila

I don't do TDD all the time, but I used it in a few strategic projects in daytime jobs. I was taught TDD in college by an excellent professor that used a similar approach as the one in the article (write a test, then write the least code that will pass it, then build from that) and I think it's a healthy and interesting way to look at TDD. Another view of TDD that I share is that it can be considered as a spec of (some strategic parts) of a system written in a programming language, which makes it unambiguous and - obviously - automatable. I've had good results in using this approach to introduce TDD to non-technical managers. I've also found that writing tests for a few corner cases and typical cases before coding is a good way to make the problem itself (what comes before the design of the first solution, as the author treats in his article) clearer in one's head.