Freedom of choice

Many discussion has been made about Designing for Testability, and why Typemock is too powerful. The most recent of them was made by Mark.

When I read most discussions I usually find that the underlying assumption is that Design for testability is better.
Well is it? (probably yes) But is it the BEST design approach? well maybe, But maybe not!
For most people however the last question is purely academic, Most mocking frameworks will limit the developer into designing in one particular way, so why bother contemplating the theoretical?

The real added value of using Typemock is the freedom to choose. Using Typemock (for greenfield development as well) will allow each developer to actually consider design alternatives and give him the freedom to choose between them. There might be a better option out there. And even if we cant find it I will always feel that just by searching I ended up in a better place.

In his post mark asks:

“why would I want to waste my brain power constraining myself
instead of having a tool do that?”

And I answer: brain power cant be wasted. Keeping your thoughts open for new alternative is at worst a good exercise for the brain allowing it to become better. From time to time new and better approaches will be found.

Mark later describes his experience when starting out TDD. My road was also quite similar, I also learnt along the way how to design my code so it can be tested and i become a better developer for it. But unlike mark I do not feel that the road has ended. Far from it, I feel that I have only started but I wont make any progress if i wont open my mind to other possibilities.

“If you approach the tool with an open mind, it can help you!”

Of course. That exactly my point. Give Typemock the chance and you might learn better ways to design your code.

  • Jacob

    Thank you! Finally someone beginning to challenge a fundamental underlying assumption in many test/mock discussions. Design for Testability, by definition, is only useful insofar as it is needed for testability. With Typemock in your stable of tools, “Design for Testability” loses meaning. Traditional DfT techniques may encourage a better understanding of Separation of Concerns and give you techniques/tool sets (IoC and DI spring to mind) that may be useful in other scenarios, but those techniques/tool sets move down the value chain. People are treating traditional DfT techniques as if they are first-order goods, forgetting that they are second-order goods dependent on Unit Testing (Typemock-less Unit Testing) to have value.