When “doing TDD,” we consciously make design trade-offs to favor testability.  Code that is easier to test can have all these other good properties: high cohesion, low coupling, clean responsibilities, and so on.  But these trade-offs do not come without a cost, and I think it’s important to keep that cost in mind.

For example, consider all the recent concern over interfaces – to summarize – we end up with a lot of single-implementation interfaces because of testability concerns and from weaknesses with our tools.  This comes at a cost of additional API complexity and friction for the developers trying to work with the code.  (This friction can be reduced by good tools like ReSharper, but it’s still friction.)

So, choose to make this design decision because you think that the benefits the decision are worth the cost – but do not make decisions based on blind groupthink, and certainly understand that there IS a cost involved.  To do otherwise is to risk falling into a trap of proselytizing the One True Path of Development, while forgetting the ACM-sanctified answer to all software architecture questions:  “It depends.”

Tony Rasa