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
|TypeMock.NET and TestDriven are now sold together – for a limited time only.
These tool complement each other and using them you can:
Write tests with TypeMock.NET and Run them from within Visual Studio with TestDriven.NET
I have been working with Jamie Consdale on integrating these tool even more
So watch out for more features.
We are offering a 25% discount for the TypeMock.NET and TestDriven.NET bundle.
As I showed in the previous post here are the other places where the TypeMock team would have loved to use TypeMock Case 2. Mocking another Process. The Tracer is a class that is used to send and recieve trace messages to the Tracer GUI. Before the tracer pushes a message into the message pipe, it checks if a GUI exists.
private bool ClientIsRunning()
// Code that checks that a Tracer GUI is up and runnning, using inter-process mutex
As I showed in the previous post here are the other places where the TypeMock team would have loved to use TypeMock
Case 2. Mocking another Process.
The Tracer is a class that is used to send and recieve trace messages to the Tracer GUI. Before the tracer pushes a message into the message pipe, it checks if a GUI exists.
In order to test the Tracer we have to fake that the client is running, without having the real GUI. We cannot set the mutex as Windows will not block mutexes in the same process.
Using TypeMock we would do the following:
|Mock m = MockManager.Mock(typeof(Tracer));
Simple, but we cannot so we did the following:
We changed the signiture of ClientIsRunning to:
|protected virtual bool ClientIsRunning|
and created a Mocked Tracer:
public class TestTracerMock : Tracer
protected override bool ClientIsRunning()
And used a technique to swap the real Tracer with our TestTracerMock. Here is how:
Our tracer is a singleton so that it can be used throught the framework:
internal static Tracer Instance
tracer = new Tracer();
We swap the Tracer by inserting the MockedTracer into the tracer field:
public void ChangeTracer()
TestTracerMock traceMock = new TestTracerMock();
We had to change the Tracers constructor to public too.
There is a saying in an ancient language: “the shoemaker walks barefoot”. This is still true in our future age, and the TypeMock creators cannot test TypeMock.NET with TypeMock.
Here are 3 places that we had to use other methods:
1. Displaying a Message
Here is the code (it is static as it doesn’t use any member fields):
|internal static void ShowMessageBox(AboutMessage msg)
We cannot run this in our tests as a MessageBox will appear and halt our tests.
If we had TypeMock.NET we could test as follows, expecting ShowMessage to be called once.
|Mock m = MockManager.Mock(typeof(TestedClass));
Simple. Here is what we had to do:
public static bool shouldMock = false;
public static int countCalls = 0;
#endif internal static void ShowMessageBox(AboutMessage msg)
We had to enable the method to not show the MessageBox in certain cases. We decided to keep it all in debug mode only so that the production code is not spoiled.
|TestedClass.shouldMock = true;
TestedClass.countCalls = 0;
TestedClass.shouldMock = false;
I am sure that there are better ways to do this, but having TypeMock would have really helped keep our code clean.
- Product Status Peek – 2011
- Thanks Roy
- Typemock starts 2011 in a new location
- Agile Demos Smells
- I want loud disputes in our meetings
- .NET Tests
- Code Integrity
- Management for Geeks
- Time Management
- Unit Tests
- January 2011
- December 2010
- October 2010
- August 2010
- May 2010
- April 2010
- March 2010
- February 2010
- December 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- December 2008
- November 2008
- August 2008
- July 2008
- May 2008
- April 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006