Mocks are not Stubs

As many before me I was recently looking at different mocking frameworks in order to find one that suited my needs, and was written in C++. And there are not many alternatives out there if you're using C++. I've found one open source and two internal (Microsoft staff can access what can be described as an internal codeplex) ones. Pretty soon it turned out that none of these frameworks did what I wanted. Actually they suggested using no framework at all for the situations I was looking to "solve" with a framework.

At this point I rediscovered an old article by Martin Fowler and it became crystal clear that the reason I didn't find what I wanted in the mocking frameworks was because I really wanted a stub framework (or rather a stub helper). Because what I wanted was a simple way to reuse the algorithm "return 17 the first 7 times called and then throw an exception after that, unless called with argument 4711 in which case you should always return 42". A pretty simple method to write in your stub if you just subclass and override the object you want to mock/stub but a little bit cumbersome in the long run if you do this a lot.

During a discussion on a company internal mailing list for TDD it became clear that people generally use the term mock object for almost every kind of non-production object used during testing. And when another large group do make the distinction between mocks, stubs, fakes and dummies you quickly run into trouble since you are no longer discussing the same thing. So here is yet another recap on what the different kinds of objects are so I can contribute to the cause, making world a better place to be. At least when talking about mocks & friends.

Object Description Comment
Dummy Passed around and should never be used. Should fail the tests if ever used.
Fake Working implementation but takes short-cuts making them unsuitable for production. For example an in memory database.
Stub Quickly responds with a small number of known values. Used during testing to mimic a certain behavior.
Mock I like to think of mocks as stubs with the knowledge of usage added. Used to verify that the user of the (mock)object makes the correct number of calls in the correct order.
Many mock frameworks are designed to make verification of number of calls and/or order optional. But if you do not verify order or number of calls you're basically using a stub (but it is generated from a mock framework).

Comments (2)
  1. First of all I must remind you that I don’t like mocks and mocks aren’t stubs . But recently I read a

  2. So I thought it was time to write a little about my lightning talk from the last Swedish ALT.NET unconference

Comments are closed.

Skip to main content