The best way to convince people to write tests is to remind them that they are already writing tests, but they're throwing them away. If you're writing a metho

The best way to convince people to write tests is to remind them that they are already writing tests, but they're throwing them away. If you're writing a method, you are almost certainly testing it with a bit of code to verify the output. You're probably writing one of these little tests every 5 minutes. Save them in a folder called "unit tests". Are you writing code to make sure one part of the API works with another? Save it in a folder called "integration tests". Opening up a browser to make sure the right stuff is appearing on the right part of the page? Save it in a folder called "functional tests". Put in a code coverage tool to make sure you're calling all the code you've written in a test - personally this usually happens when I "got rid" of code without actually getting rid of it (rot). I mainly work in Ruby and Rails these days, and I'll concede that it all gets a little blurred (and I did plenty of handwaving in that previous paragraph, but you couldn't see it because I was typing). But as long as you're doing something like that, I really do think you'll end up with a well tested app with full coverage. TDD? Well, sure, I've done it, but I'm not going to insist on it, for myself or anyone else. You could write that integration test first, or you could write it iteratively. You could write a functional test that makes sure a bit of text is present on a web page, and then write the the code that generates that bit of text, or the other way around. I don't see it making a big difference - other than that forcing people to write the test first can be a mental intrusion that badly disrupts their thinking process on certain types of tasks. In spite of all that, I (like a lot of people on HN, regardless of where they stand on TDD) would welcome a compelling rebuttal of DHH's recent blog post.