There has been much talk about Designing for Testability lately.
Basically the argument is:
Should our Tests (Enabling Mock Insersions) Drive our design?
or should we use tools to do it for us?
Here is what 14 of are our community have to say about it:
- Pondering Mocks – Tim Haughton,
Tim is debating Designing for Testability
“On first inspection, I thought this was fantastic… But after my dizzy elation, a sobering thought entered my head. One of the major benefits [is] … that we arrive at very loosely coupled code. This benefit would never occur…”
- Stop designing for Testability? – Stewart Robertson
Stu is seeing some logic in using tool to insert mocks but is waiting for backing from the community.
“It does sound very plausible – although it would be interesting to see what other people in the TDD community think – personally I think atm that the need for the extra infrastructure to support our tests is the biggest drawback to developers in our team (D&I)from picking up and running with it. The simpler we can keep it, the less resistance we will get.”
- TypeMock – Helps Improve Your Designs? – Colin Jack
Jack debates our questions:
“For me the question is whether designing your code for testability is actually a good idea, if so using TypeMock too much is a bad idea.
Personally I’m much in favor of TDD but I think I disagree with most of the books/Websites because I don’t think that decoupling your code to allow mocking necessarily results in particularly good designs.”
- Unit Testing in .NET – Kent Boogaart
Kent talks about the problems of designing for testablility, but has no solution yet.
“I shall continue on my quest for the holy grail by taking a look at TypeMock.NET’s abilities.”
Are basically against using tools except for legacy code.
- Tools instead of testability – Marcus Widerberg
Marcus is debating the issue, with no clear answer yet.
“What I feel is very wrong, however, is using the capabilities provided by Typemock as an excuse to create bad quality, highly coupled and unmaintainable code. When you are starting anew, seize the opportunity! Do it right! “
- Concrete vs. Abstract Type Mocking & Interaction vs. State Based Testing -Paul Eastabrook
Paul Changed his mind and now finds places where TypeMock has value.
“Someone has finally convinced me that TypeMock might not be all bad – chrs OJ. You see, I detest the idea of concrete type mocking, as I strongly feel it misses half the point of mocks, which is discovering class design”
- Benefits of Testability – Jay Flowers
Jay believes that writing testable code has great benefits
“TypeMock is a powerful application but I think that it can be misused to allow poor design with ease of unit testing… unit testing and testability are like an alarm indicating early that there is a design problem”
- How to mock a static member for test-driven development – Jeffrey Palermo
Jeffrey belives that one shouldn’t use statics, and it is better to redesign your code.
“Using statics all over the place will kill your software. Perhaps you called my bluff when I said “you cannot mock a static.” Ok, you win. My next question is: Do you really _want_ to mock a static?”
- Stop Designing for Testability – The Code Project – .NET – Eli Lopian
Here I talk about the need to isolate you code for higher test coverage and ways to do it.
“Although creating interfaces… is considered a good O/O practice, if taken to the extreme it clutters our code. We should be able to decide what the best design is for the production code without changing it to make our code testable. …so we should STOP kidding ourselves, there is no need to change our design to make our code testable. The Production Code and features should drive our Design not our tests.”
- Mock objects: Sealed doesn’t suck as much as it used to – Anders Noras
Andres talks about using sealed classes and unit testing
“Thanks to TypeMock.NET sealed doesn’t suck as much as it used to.”
- TypeMock.Net and mocking interfaces using Dynamic Mocking – Adrian Spear
Adrian talks about using TypeMocks to test external components that were not built with mocking in mind
“The main benefit that I have seen so far has been that it is now possible to mock out 3rd party components which were probably never developed with test driven development in mind. I have successfully produced an integration test assembly which we run against each new version of the component we receive which verifies that it still behaves consistently – I can then produce unit tests against all my component client classes with a mocked out component which is very handy to avoid the very time consuming internal initialisation.”
- Mocking static methods – Stephan Zahariev’s
Sephan is happly mocking static methods with TypeMock.NET
“Although TypeMock is powerful and easy to use library, there are some disadvantages. “
- unit testing and mocking frameworks – John Spano
John had started to write tests again since encountering TypeMock.NET
“I highly suggest you check it out if you do unit tests, or you were like me and didn’t like them.”
- Using TypeMock.NET to mock a external dependency – Maruis Marais
Maruis finds using TypeMock.NET
“Will this ability to easily mock these dependencies now cause us to write code that is more coupled due to the fact that we don’t have to think so much about designing our code with testing in mind? Maybe, it will. But I think that the ability that TypeMock.NET gives us, will help us to write better tests giving us better code coverage and the ability to produce well tested code faster. The only problem is that TypeMock.NET is a commercial product, which will hamper the adoption of the framework.”
Now all you have to do is decide for yourself 🙂