Comments on: Mocks versus stubs and fakes

By: Louis Vuitton Handbags

Louis Vuitton Handbags — Tue, 26 Oct 2010 08:38:25 +0000

Hi webmaster, commenters and everybody else !!! The blog was absolutely fantastic! Lots of great ED Hardy Handbagsinformation and inspiration, both of which we all need!b Keep 'em coming... you all do such a great job at such Concepts... can't tell you how much I, for one appreciate all you do!

By: Web Design Company

Web Design Company — Thu, 07 Jan 2010 06:07:39 +0000

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.

By: mendicant

mendicant — Tue, 13 Oct 2009 20:53:40 +0000

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();
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.

By: Nikola Malovic

Nikola Malovic — Tue, 13 Oct 2009 19:11:40 +0000

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

By: Scott

Scott — Tue, 13 Oct 2009 16:32:55 +0000

Oh, and SUT stands for “System Under Test”. It refers to the method you are testing at the time.

By: Scott

Scott — Tue, 13 Oct 2009 16:25:51 +0000

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?

By: Nikola Malovic

Nikola Malovic — Tue, 13 Oct 2009 16:17:00 +0000

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.

By: JonR

JonR — Tue, 13 Oct 2009 12:44:48 +0000

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.)

By: Dew Drop – October 13, 2009 | Alvin Ashcraft's Morning Dew

Dew Drop – October 13, 2009 | Alvin Ashcraft's Morning Dew — Tue, 13 Oct 2009 12:21:57 +0000

[...] Mocks versus stubs and fakes (Scott Koon) [...]

By: Scott Bellware

Scott Bellware — Mon, 12 Oct 2009 22:08:29 +0000

Can we conceive of a better design of the IDataReader that would make mocking it less verbose?