When testing a system, known as the System Under Test or SUT, the system needs to have access to its dependencies but often the access given is just clever mimicry. Testing doubles are used to replace a system’s dependencies with varied functionality. The article “Test Doubles — Fakes, Mocks and Stubs,” by Michal Lipski, explains three out of five of the types of testing doubles defined by Gerard Meszaros, fakes, stubs, and mocks. The author provides diagrams and code examples with explanations for the testing doubles.
The first testing double described in the article are fakes. The article provides the example of a SUT that depends on a Data Access Object or DAO. In this case, a fake is used to replace the DAO so that the SUT can be tested without the need of using a real database.
Stubs are the next testing double type discussed in the article. Stubs are the simplest testing double type as they only provide canned responses. These responses are predetermined and are used in place of actual data.
The last type in the article are mocks. Mocks are used for Behavioral Testing. Mocks allow for testers to be able to verify the system is behaving correctly, correct methods called at correct times. A simple case for a mock is when a SUT depends on a method that does not return anything that can be verified. The mock object will record when its methods are used, so that the behavior can be checked.
I found the example diagrams in “Test Doubles — Fakes, Mocks and Stubs,” by Michal Lipski, very helpful in understanding the differences of the testing doubles. While this article does not go over two types of testing doubles, dummies and spies, the three types that are discussed are described well. Ultimately, when testing a system, it is imperative that the system can test all its behaviors without relying on actual data.