Background
Over the years I’ve heard many customers ask us to ship a mocking framework in Visual Studio. I was always a bit cautious about providing this for a few different reasons.
First, I’ve always been hesitant to recommend “mocks” when unit testing, preferring stubs in most cases. For anyone unsure of the difference between a Mock and a Stub, I suggest you read Martin Fowler’s excellent article Mocks Aren’t Stubs.
On the one hand there is a difference in how test results are verified: a
distinction between state verification and behavior verification. On the other
hand is a whole different philosophy to the way testing and design play
together…
Martin Fowler Mocks Aren’t Stubs
Basically a stub is a test fake (or dummy) that is used as a stand-in for the real type. You do this to avoid having to pass in a real object, which would extend your test beyond the realm of “unit”. They are frequently used when doing classical “Arrange, Act, Assert” state-based testing. A mock, on the other hand, provides not only a fake implementation but also logic for verifying how calls were made on the fake. When you are testing side- effects, protocols and interactions between objects, they are extremely valuable.
The concern is that I have often seen people fall into using behavior verification where none is needed. Overuse of mocks inhibits free refactoring of the code because, as Martin discusses in his essay, it leads to a very tight coupling between the tests and the implementation instead of just to the interface contract. I might blog more on this later, but let’s keep going.
The second reason for my reluctance was that there are quite a few good Mock/Stub implementations available in the community. Moq, Rhino, NMock and others have strong followings and good reputations and I wasn’t sure I wanted to get into the business of competing with them.
But despite the misgivings about competing with community driven projects, there was continued feedback from customers asking for help from Visual Studio in making fast-running, isolated unit tests. A part of this is because many customers are unable to use open-source or third-party tools. Another part is simplicity: people would rather have what they need on-hand, in the box.
Introducing Visual Studio 11 Fakes
In the end, it was decided that we would make an investment in this area for Visual Studio 11. In VS11 Beta we included the first publicly available version of the VS Fakes framework. Our goal with the Fakes framework is to enable developers to quickly and easily isolate their unit tests from their environment.
Read more: Peter Provost's Geek Noise
QR: 
Posts
0 comments:
Post a Comment