The author makes four criticisms of TDD: 1) That having a test suite tends to makes a programmer conservative, to avoid breaking tests. But in a team environme

The author makes four criticisms of TDD: 1) That having a test suite tends to makes a programmer conservative, to avoid breaking tests. But in a team environment, this kind of conservatism is a feature, not a bug. 2) That there are cases where the code that is easiest to test is not the best code. In my experience this is the exception rather than the rule. 3) That TDD causes the programmer to focus on the details rather than the overall design. This is a valid criticism, but the way to remedy it is to build prototypes and toy code before diving into the actual implementation. Here again, if you're a lone programmer working on a pet project, you're not going to see much distinction. But on a larger project with a team of programmers, such rapid prototyping is very useful. As they say, "build one to throw away". 4) The author has trouble designing tests for bad input. I'll take him at his word, but I've never found those kinds of tests to be that difficult; if anything, they tend to be boilerplate. Certainly when you're talking about validating complex input like JSON objects, it's not trivial, but there are libraries to handle most of those kinds of real-world situations.