I totally understand what you mean. I've gone to great lengths to determine what kind of architecture is needed to truly support TDD and what I've come to real

I totally understand what you mean. I've gone to great lengths to determine what kind of architecture is needed to truly support TDD and what I've come to realize is that it's not so much about over-abstraction that is the problem, it's that testable code is pluggable, which is mostly at odds with how systems are designed. For example, standard MVC apps tend to tie models to an ORM in some way shape or form. Think Rails and ActiveRecord and you'll understand what I mean. This makes writing a simple crud app fast, but testing it sucks because you have 2 things tied together - your actual data models and your database layer. Funny that nobody would ever do that with the filesystem, but it's super common with the database. To make your models clean and easy to test, you need to pull out the ORM bit into something more pluggable. The same principle applies to writing testable biz logic. A lot of times people don't know where to put it so it ends up in the View, Controller, or Model. All of which are the wrong place usually. Testing that code becomes not awesome because you then have to write a test against what the view outputs, the controller does, or possibly what the model is doing (usually by touching the database). The answer I've found is to pull your business logic into a separate container that can be tested easily apart from any MVC structure. None of this means you need to over-abstract anything. It just means you have to figure out the right abstractions and structure for the right layers. None of this is by any means obvious at first. P.S. I'm working on an architecture framework that simplifies a lot of this to make doing TDD much easier.