"Prevent imagination overrun"<p>Sounds like taking all the fun out of it. I guess TDD is ok if you have a boring clear idea of what code monkey thing needs churning out, but if you're just exploring, playing around and experimenting with what can be done with a tight development cycle I don't see how TDD can really work.<p>It's like the kid who draws out and designs all his lego creations before he touches any lego, as opposed to the kids that just play around trying cool stuff.
To quote the classic: "During their operations they seem to focus entirely on the process, but very little on the quality of the code. Sorry guys, but having a 1:4 code:test ratio is not focusing on code quality. It's focusing on test quality."[<a href="http://zedshaw.com/rants/rails_is_a_ghetto.html" rel="nofollow">http://zedshaw.com/rants/rails_is_a_ghetto.html</a>]
This article is exactly right if you have a concrete functional spec of what the code is supposed to do. It's advantages become crystal clear when you have multiple developers on the same codebase and are coding in a lower-level language. It is mechanistic and dull but it works.