I've heard this argument a lot, but some of the worst codebases I've ever worked with have been heavily test-driven code. The need to have a failing test for ev

I've heard this argument a lot, but some of the worst codebases I've ever worked with have been heavily test-driven code. The need to have a failing test for every line of code combined with a tunnel-vision devotion to YAGNI and working in small pieced ended up creating these elaborate layers of functions that did no useful work except glue test cases together. Straighforward refactoring that might have taken an hour or two ended up taking days because every few keystrokes had to be validated by intermediate tests that would be invalidated by the next incremental phase of the refactor. Granted that particular team was an extremely low-skill team in general, and I've used TDD now and again successfully when it fit my needs, but that experience was a pretty strong counter-example to the strong claims made by TDD proponents about how it improves the quality of code.