[MattBearman]

Personally I completely disagree with this, I've never found myself randomly changing code in a desperate attempt to get a test to pass.

Maybe it's because I'd been coding for years before I ever tried TDD, but when a test fails, I logically debug the code the same way I would if I wasn't using TDD.

As far as I'm concerned having tests just flags possible errors much quicker, and also gives me more piece of mind that my code isn't gonna be riddled with hidden bugs.

[Erwin]

An often touted "benefit" of TDD is that "addictive" feeling when you write tests and see them pass. "you feel like you have done a lot because you have a lot of code"; "you feel a great deal of accomplishment". Quite a few pages talk about it when you search for "tdd addictive".

The canonical example is the master of XP solving Sudoku in the TDD way: http://xprogramming.com/articles/oksudoku/ (part 1 out of 5) -vs- Peter Norvig: http://norvig.com/sudoku.html

[typicalbender]

I also disagree with this article. I think the point of TDD is not to blindly mash at the keyboard to make tests to pass and TDD encourages you to go back and refactor code and tests after you get it passing. TDD gives you confidence that the functionality you developed yesterday doesn't break when you add more functionality today.

TDD isn't a be all and end all, its just one more tool in a developers toolbox that allows us to be better at your job. If you solely rely on TDD or [Insert newest popular development technique] you are going to have a bad time.

One place that I've found TDD to be insanely helpful is exposing the interaction between pieces of the system before building it out in code. I tend to write my tests from the bottom up, i write the assertion first, and then build up the stuff i need to test that assertion. This makes it easier to see whats needed to test the functionality and whether or not the test looks good or not.

Gary Bernhardt does a really good job at explaining his philosophy on TDD, which I really agree with, http://destroyallsoftware.com

[jasonlotito]

The other thing to consider is that if you don't know what changed between code change and test running, you aren't running your tests often enough. When you make a change, you test that change. That change should be small enough that it makes it clear where the problem lies.

[ddfreyne]

I believe it boils down to a matter of discipline.

If you say that you never randomly modify code in order to make it work (according to the tests), then that is great, and that is how every developer should work. However, my experience is that people who lack discipline (or face a looming deadline) tend to not take their time to properly reason about code and instead rely on the test suite to tell them whether code is right or not.