What's the difference between a mock & stub? – Dev

The best answers to the question “What's the difference between a mock & stub?” in the category Dev.

QUESTION:

I’ve read various articles about mocking vs stubbing in testing, including Martin Fowler’s Mocks Aren’t Stubs, but still don’t understand the difference.

ANSWER:

Stub

I believe the biggest distinction is that a stub you have already written with predetermined behavior. So you would have a class that implements the dependency (abstract class or interface most likely) you are faking for testing purposes and the methods would just be stubbed out with set responses. They would not do anything fancy and you would have already written the stubbed code for it outside of your test.

Mock

A mock is something that as part of your test you have to setup with your expectations. A mock is not setup in a predetermined way so you have code that does it in your test. Mocks in a way are determined at runtime since the code that sets the expectations has to run before they do anything.

Difference between Mocks and Stubs

Tests written with mocks usually follow an initialize -> set expectations -> exercise -> verify pattern to testing. While the pre-written stub would follow an initialize -> exercise -> verify.

Similarity between Mocks and Stubs

The purpose of both is to eliminate testing all the dependencies of a class or function so your tests are more focused and simpler in what they are trying to prove.

ANSWER:

Foreword

There are several definitions of objects, that are not real. The general term is test double. This term encompasses: dummy, fake, stub, mock.

Reference

According to Martin Fowler’s article:

  • Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
  • Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).
  • Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it ‘sent’, or maybe only how many messages it ‘sent’.
  • Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

Style

Mocks vs Stubs = Behavioral testing vs State testing

Principle

According to the principle of Test only one thing per test, there may be several stubs in one test, but generally there is only one mock.

Lifecycle

Test lifecycle with stubs:

  1. Setup – Prepare object that is being tested and its stubs collaborators.
  2. Exercise – Test the functionality.
  3. Verify state – Use asserts to check object’s state.
  4. Teardown – Clean up resources.

Test lifecycle with mocks:

  1. Setup data – Prepare object that is being tested.
  2. Setup expectations – Prepare expectations in mock that is being used by primary object.
  3. Exercise – Test the functionality.
  4. Verify expectations – Verify that correct methods has been invoked in mock.
  5. Verify state – Use asserts to check object’s state.
  6. Teardown – Clean up resources.

Summary

Both mocks and stubs testing give an answer for the question: What is the result?

Testing with mocks are also interested in: How the result has been achieved?

ANSWER:

Here’s a description of each one followed by with real world sample.

  • Dummy – just bogus values to satisfy the API.

    Example: If you’re testing a method of a class which requires many mandatory parameters in a constructor which have no effect on your test, then you may create dummy objects for the purpose of creating new instances of a class.

  • Fake – create a test implementation of a class which may have a dependency on some external infrastructure. (It’s good practice that your unit test does NOT actually interact with external infrastructure.)

    Example: Create fake implementation for accessing a database, replace it with in-memory collection.

  • Stub – override methods to return hard-coded values, also referred to as state-based.

    Example: Your test class depends on a method Calculate() taking 5 minutes to complete. Rather than wait for 5 minutes you can replace its real implementation with stub that returns hard-coded values; taking only a small fraction of the time.

  • Mock – very similar to Stub but interaction-based rather than state-based. This means you don’t expect from Mock to return some value, but to assume that specific order of method calls are made.

    Example: You’re testing a user registration class. After calling Save, it should call SendConfirmationEmail.

Stubs and Mocks are actually sub types of Mock, both swap real implementation with test implementation, but for different, specific reasons.

ANSWER:

A stub is a simple fake object. It just makes sure test runs smoothly.
A mock is a smarter stub. You verify your test passes through it.