What I mean by this, is that sometimes architects look to simplify and improve testability, at the expense of other important forces.
For example, I’m reviewing a very complicated application, made so by extensive use of design patterns that overly favor testing, e.g. IoC, DI, AOP, etc…
Now, typically I like these things, but this system should have been much simpler – though not just a simple web frontend for CRUD on a db, it still not MUCH more complicated than that (even considering some internal workflows, processes, etc). On the other hand, just reviewing the code becomes a major pain in the heinie, barely readable (even though its well written), and coding it must have been a pain.
The implemented complexity is a clear violator of KISS (the principle, NOT the band)… and the “only” benefit is improved testability, using testing frameworks and mocks and and…
Now, before you TDD fans jump me, I’m not belittling the importance of testability, but I’m questioning the supremacy of consideration of this specific force (against all the others).
Or did I miss something?
I’d like to add another point – it does seem to me that all this talk of “testability” is with regards specifically to unit testing, which differs from overall system testing, and can result in missed tests when the individual units are integrated together. At least, that seems the point of the IoC/DI for testing…
Also, I’d point out that this system (and others I’ve seen preached) only have a single concrete object per interface, and the IoC/DI is only intended for – you guessed it – replacing the concrete objects with testing mockups for testing only.
I felt the need to add this quote from Wikipedia on IoC:
Whereas the danger in procedural programming was to end with spaghetti code, the danger when using Inversion of Control is ending with macaroni code
Yup, that expresses my feeling exactly 😀
To answer your general question, I’d say “everything in moderation”. An emphasis on testability is of course a great thing. But not when it comes at the cost of excluding, say, readable code or a logical API.