I'm seeing a lot of misconceptions about test-driven development in this thread. The biggest one is that test-driven development involves writing a bunch of tes

I'm seeing a lot of misconceptions about test-driven development in this thread. The biggest one is that test-driven development involves writing a bunch of tests first. Instead, TDD involves interweaving tests and production code in a very tight cycle. You write a few lines of test code, then a few lines of production code, then you review and improve your code, then write a few lines of test code, and so forth. Each step only takes a minute or so. This is useful because you're constantly making and checking hypotheses: "This code should make a test fail in X way... yup. Okay, now this code should make the test pass. Yup. Now this change shouldn't change behavior, and the tests should still pass. Oops! Undo. Oh, that method has to be called in the constructor. All right, this change should work. Good." (If you're interested, my book goes into more detail, and it's online: http://jamesshore.com/Agile-Book/test_driven_development.html http://jamesshore.com/Agile-Book/test_driven_development.htm... . I also have a extensive screencast of real-world TDD here: http://jamesshore.com/Blog/Lets-Play/ http://jamesshore.com/Blog/Lets-Play/ ) Despite the extremists, TDD really is a useful tool--and that's all it is. Sure, TDD has been turned into yet another vehicle for programmers to engage in religious wars, but you can't really blame TDD for that, any more than you can blame Richard Stallman for emacs vs. vi wars.