chapter six

6 Test doubles and mocks

 

This chapter covers

  • Using stubs, fakes, and mocks to simplify testing
  • What to mock, when to mock, and when not to mock
  • How to mock the unmockable

Up until now, we have been testing classes and methods which were quite isolated from each other. We would pass the inputs to a single method call and assert its output. Or, when a class was involved, we would set up the state of the class, call the method under test, and assert that the class is in the expected state.

Some classes, however, depend on other classes to do their job. Exercising (or testing) many classes together might be something desirable. After all, we often break down complex behavior into multiple classes to improve maintainability, each with a small part of the business logic. We do still want to ensure, however, that the whole thing works together. This is something we will discuss in Chapter 9 (Larger tests). In this chapter, we are going to focus on when we really want to test that unit in an isolated fashion, without "caring" too much about its dependencies. But why would we want that?

6.1 Dummies, fakes, stubs, spies, and mocks

6.1.1 Dummy objects

6.1.2 Fake objects

6.1.3 Stubs

6.1.4 Mocks

6.1.5 Spies

6.2 An Introduction to mocking frameworks

6.2.1 Stubbing dependencies

6.2.2 Mocks and expectations

6.2.3 Capturing arguments

6.2.4 Simulating exceptions

6.3 Mocks in the real world

6.3.1 The disadvantages of mocking

6.3.2 What to mock and what not to mock?

6.3.3 Date and time wrappers

6.3.4 Mocking types you do not own

6.3.5 What do others say about mocking?

6.4 Exercises

6.5 Summary

6.6 References