I think you've identified one of the weakest parts of the essay. This is about ignoring testing, not TDD. One way I've convinced people to write unit tests is

I think you've identified one of the weakest parts of the essay. This is about ignoring testing, not TDD. One way I've convinced people to write unit tests is to remind them that they are already testing. People often write a little main to check the output of a program. This is a test. People often click on a link to validate that some text is present. This is a test. Keep them! Instead of throwing away your stand alone program, put it in the unit test folder. Instead of throwing away that point and click, automate it and put it into the integration tests folder. This alone will get you close to 100% coverage. Now, when you refactor your code and it no longer works the way you verified it would a while ago, you'll get a little red bar or a "FAIL" message. Usually this is because you wanted the behavior to change, so update the test. Occasionally, this is because you introduced unwanted side effects in your code, which is exactly why you want these tests. TDD is substantially different from what I just described. If the author wants to defend it, that's fine, but let's make sure we understand it's not the only way to get high levels of code coverage.