For some time now, I've been reading Jeff Langr's series on TDD (including testing equality, refactoring tests, and driving UIs). I now feel compelled to make sure I link to it as it's up to the 13th installment "Nine Reasons Why You Should Be Using TDD".
"A lot of the duplication in a system isn’t evident until you start refactoring. Once you begin refactoring, you start recognizing potential for reuse. You’re more likely to recognize that a small, newly extracted method could be called by another method, which in turn simplifies the other method. You start to build simpler classes that do fewer things. Often, having a smaller class increases the likelihood that other classes can reuse it."
I'd like to call this the "Tetris effect" of refactoring code. You get methods/classes/lines of code looking the same, all at the same level of abstraction and any extra complexity can then be easily removed.
"I used to think that I was a pretty good coder. I would spend an afternoon slamming out code. I’d integrate the code and run some manual tests late in the afternoon. Sometimes it wouldn’t work—imagine that! I’d then be forced to spend another few hours unraveling the mess I’d built."
"With TDD, every piece of code exists because it was required by a test. That rule, in turn, means that we have solid unit test coverage. (We don’t have exhaustive coverage, which would be virtually impossible to provide.) Defect rates should come down significantly. Martin Fowler and Ron Jeffries talk about shops that severely reduced their numbers of defects. Most teams working on moderate-sized applications (several hundred thousand lines of code) have defect rates in the hundreds or even thousands per year. Shops doing TDD can achieve rates of less than a dozen per year (but they probably need to be adhering to other proven disciplines as well)."
"The amount of time I feel compelled to go off into a dark cube and think about a problem has been minimal since I’ve been doing TDD."