Mocks versus stubs and fakes
I dislike using mocks I dislike using dynamic mocking/stubbing frameworks. because it means my tests have an extra dependency beyond just the SUT (System Under Test). I often find myself spending more time getting the mock to work correctly rather than my app code. The lambada + generics based Mock suites (Moq, RhinoMocks, etc), IMO, complicate the test and make them unreadable in some situations.
Compare the two examples in this post. One uses RhinoMocks to create a stub of IDataReader and the other uses the DataTableReader to create a stub for the test. Which example is simpler and has less chance to fail due to the stub?
http://www.lazycoder.com/weblog/2008/12/12/mocking-idatareader-using-rhinomocks-35/
Using RhinoMocks
-
IDataReader reader = MockRepository.GenerateStub<IDataReader>();
-
reader.Stub(x => x.Read()).Return(true).Repeat.Times(1);
-
reader.Stub(x => x.Read()).Return(false);
-
reader.Stub(x => x["ID"]).Return(Guid.Empty);
-
reader.Stub(x => x["FullName"]).Return("Test User");
Using DataTableReader
Stubs/Fakes allow me more control over HOW the test fails and results in a test/fixture that is easier to read. I'm not saying that mocks aren't useful in certain situations, but I would favor a stub over a mock IMO, your test should only fail because of the code it is testing, not because of a mock.
Although it is fun to say "Mock ME? No mock YOU!".
update: I forgot to link to Rob's post that inspired this post. "Using Dependency Injection and Mocking For Testability"
update to the update: Jeremy Miller and Nikola Malovic both pointed out that I'm using the terminology incorrectly. It turns out I don't specifically hate mocks themselves, I dislike use dynamic mocking/stubbing frameworks due to the extra dependency they introduce into my tests. Thanks for the corrections. Back to reading Fowler for me!
The Lounge
TwitterCounter
What I'm Doing...
- Nodul.es, CPAN for node.js http://bit.ly/cYGGwO 4 mins ago
- Dude at Seattle Center managed to schedule my daughters birthday part for a month too early. Here's to you calendar challenged dude! <clink> 1 hr ago
- Just got the best captcha ever. "In urbuthwa" 3 hrs ago
- More updates...
Powered by Twitter Tools
Books I’ve worked on
Contributors
Links
Herding Code Podcast
- Herding Code 92: Dru Sellers and Rob Reynolds on Nu 8/27/2010
- Herding Code 91: Listener-Powered Lightning Round 8/19/2010
- Herding Code 90: Sara Chipps on Girl Develop IT and Girls Developing Software 8/12/2010
- Herding Code 89: Vaidy Gopalakrishnan on IIS Developer Express 8/5/2010
- Herding Code 88: Julie Lerman on Entity Framework 4 7/21/2010
October 12th, 2009 - 15:08
Can we conceive of a better design of the IDataReader that would make mocking it less verbose?
October 13th, 2009 - 05:44
i don’t think i’ve ever mocked or stubbed ADO.NET, isn’t that considered a bit of a no-no?
(actuallly now i come to mention it, i can’t remember the last time i used ADO.NET directly anyway. ignore me.)
October 13th, 2009 - 09:17
Nut sure what SUT is but IMHO your business logic shouldn’t have a dependency on IDataReader at all (hiding it in Repository bowels is just one way to do that)
In toher words, if you ended mocking IDataReader maybe it is time to revisit your design one more time.
October 13th, 2009 - 09:25
Scott: Agreed, ideally I’d like to see mocking/stubbing built INTO the framework. But the IDataReader interface itself is rather large. All those messy Get{type} methods. Bleh.
Nikola: Also agreed. But what if you are testing your data access layer? Even if you put it in a repository, you’ll probably want test coverage on the repository right?
October 13th, 2009 - 09:32
Oh, and SUT stands for “System Under Test”. It refers to the method you are testing at the time.
October 13th, 2009 - 12:11
Well, IMHO you should be mocking\stubing\faking only the dependencies not the SUT itself being tested.
In my code my unit tests would take care about behaviors such is “make sure that in case x business logic made a call to mocked method Y on infrastructure.”, but I would have separate integration test(s) for the implementation of method Y where (same as you in this post) I stay away as much as possible from any mocks and try to “keep it real” as much as I can.
Btw, I think I know why mocks “doesn’t make sense” to you.
Based on your examples, you use the mocking framework to “setup the state” (completely valid usage of stubs) but the mocks itself are not supposed to be used in that scenarios but instead they should be used in behavior type of tests.
I guess what I try to say is that I agree with you in finding that the mocks doesn’t make any sense used in this context
October 13th, 2009 - 13:53
The thing I often find is that when you start having to stub out framework implementations you’re almost always better off to just create and pass in an instance tailored to your test.
For example:
A) var customers = MockRepository.GenerateStub<IEnumerable>();
B) var customers = new List { new Customer() }; // Or a mock of the customer… whatever
I’ll pick B every time because it just makes more sense. If I do A then do I have to start stubbing out an enumerator? access? I’m willing to accept that MS will (should?) have the framework covered so I’m not afraid to use actual implementations in my tests.
I’ve been down the mocking path before and I find that like you said, I just end up stubbing values that I really, really don’t care about.
January 6th, 2010 - 23:07
The terminology around the various kinds of Test Doubles is confusing and inconsistent. Different authors use different terms to mean the same thing. And sometimes they mean different things by the same term.