> To get the tests working, you end up having to write a lot more infrastructure and abstraction to support it. So you end up with 6 classes where one would do,

> To get the tests working, you end up having to write a lot more infrastructure and abstraction to support it. So you end up with 6 classes where one would do, because you end up needing an extra interface, and then impl, and then mocks, and dependency injection and on and on. I have found this to be true only when having to work with code that was not written with TDD. For example, if you're writing a new Rack middleware, it will be EXTREMELY easy to TDD and unit test. The entire Rack design (while not devoid of criticism) is sort of ingeniously simple and was clearly written with TDD/unit testing in mind as a design priority. However, if you're interested in TDD'ing a Rails controller without loading your entire stack... Good luck with that. But Rails was NOT written with TDD, nor unit testing, in mind. It's evident right in the Rails lingo- a "unit test" in Rails is (was?) a test of the model code (and everything underneath). A "true" unit test doesn't test dependencies (so for example, an ACTUAL "unit test" of model code would abstract out the entire database and mock out all the CRUD operations). So I guess I could paraphrase what you're saying as, "If you have to TDD and, in the course of this particular development work, you have to work with code that was not written via TDD, you're going to have a bad time."