I've come to consider the main advantage of TDD is that you're more sure your tests are correct when you write a failing test, change a little bit of code, and

I've come to consider the main advantage of TDD is that you're more sure your tests are correct when you write a failing test, change a little bit of code, and then seen the test past. You then know the test is related to the changes you made, and that the test does it's purpose of preventing accidental regression of the new feature. I have written unit tests around existing functionality, and the unit tests pasts the as soon as I'm done writing it, but then I go mess up the code, and the test still passes -- turns out my tests wasn't testing anything useful. To me, this is the problem TDD avoid. You can also avoid the mentioned problem by writing production code first, and then writing the test, but then double checking that the test actually does fail when it's suppose to. I consider it important to see whether each test passes and fails in the right conditions, and this request that I see each test past and fail at least once. TDD does this, but so do other methods. I also remember that the version control doesn't know what order I wrote the code in (unless I break up the commits). My team might be crazy into TDD, but as long as I check in code with good tests, they don't know whether I wrote the tests first or not.