Search The Blog
Latest Posts
Twitter: @RoyOsherove
About this site

TDD in .NET Online Course

TDD and BDD in Ruby Online Course



This site aims to connect all the dots of my online activities - from tools, books blogs and twitter accounts, to upcoming conferences, engagements and user group talks.

« Synchronize Team System and ClearCase with the TFS Migration & Synchronization Tool | Main | Tip: Easily change logon settings for all users on your machine »

Mocks and Stubs - The difference is in the flow of information

In class today when explaining the difference between stubs and mocks, I realized a simple explanation to this:

Stubs and mocks may seem the same but the flow of information from each is very different.

  • Stubs provide input for the application under test so that the test can be performed on something else.
  • Mocks provide input to the test to decide on pass\fail. the opposite direction.

The following diagram shows the flow of critical information:


The red arrows signify the "critical" flow of information that is used to decide if the test had passed. A stub can never fail a test, so there is no flow of information back to the test. the mock records things and then tells our test if it's expectations have been met according to its recording.

A stub is application facing, and a mock is test facing. Here's a more in depth overview of the two, but I haven't seen this explained as I just did anywhere. It's important to know and distinguish the two since many frameworks for mocking use these terms for different kinds of objects.

PrintView Printer Friendly Version

Reader Comments (1)

The "recording" call is used by most "classic" mocking frameworks, but it's not really necessary (nor helpful, in my opinion). For example, Mockito in the Java world allows you to define a mock and verify it at the very end of the test. It records everything it receives when called by the application under test.

Mockito also blurs the destinction between a "mock" and a "spy" as defined by Gerard Meszaros: By the time you call verify(), it checks whether the tested component called the mock with the correct arguments - however, it will raise an exception that produces a stack trace pointing to the place where the component called the mock with the *wrong* arguments - which is really smart, since it points you right to the point where the component under test fails the test. So it behaves like a spy, but is tested like a mock (which is a bit confusing when you first see it)

June 8, 2011 | Unregistered CommenterBob Lauer

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
Web Analytics