Test Doubles - Fakes, Mocks and Stubs.
Test Doubles — Fakes, Mocks and Stubs. | by Michal Lipski | Pragmatists
This text was originally posted at Pragmatists blog
In automated testing it is common to use objects that look and behave like their production equivalents, but are actually simplified. This reduces complexity, allows to verify code independently from the rest of the system and sometimes it is even necessary to execute self validating tests at all. A Test Double is a generic term used for these objects.
Although test doubles come in many flavors (Gerard Meszaros introduced five types in this article), people tend to use term Mock to refer to different kinds of test doubles. Misunderstanding and mixing test doubles implementation may influence test design and increase fragility of tests, standing on our way to seamless refactorings.
In this article I will describe three implementation variations of testing doubles: Fake, Stub and Mock and give you examples when to use them.
Fake
Fakes are objects that have working implementations, but not same as production one. Usually they take some shortcut and have simplified version of production code.
An example of this shortcut, can be an in-memory implementation of Data Access Object or Repository. This fake implementation will not engage database, but will use a simple collection to store data. This allows us to do integration test of services without starting up a database and performing time consuming requests.
Apart from testing, fake implementation can come handy for prototyping and spikes. We can quickly implement and run our system with in-memory store, deferring decisions about database design. Another example can be also a fake payment system, that will always return successful payments.
Stub
Stub is an object that holds predefined data and uses it to answer calls during tests. It is used when we cannot or don’t want to involve objects that would answer with real data or have undesirable side effects.
An example can be an object that needs to grab some data from the database to respond to a method call. Instead of the real object, we introduced a stub and defined what data should be returned.
Instead of calling database from Gradebook store to get real students grades, we preconfigure stub with grades that will be returned. We define just enough data to test average calculation algorithm.
Mock
Mocks are objects that register calls they receive. In test assertion we can verify on Mocks that all expected actions were performed.
We use mocks when we don’t want to invoke production code or when there is no easy way to verify, that intended code was executed. There is no return value and no easy way to check system state change. An example can be a functionality that calls e-mail sending service.
We don’t want to send e-mails each time we run a test. Moreover, it is not easy to verify in tests that a right email was sent. Only thing we can do is to verify the outputs of the functionality that is exercised in our test. In other worlds, verify that e-mail sending service was called.
Similar case is presented in the following example:
We don’t want to close real doors to test that security method is working, right? Instead, we place door and window mocks objects in the test code.
After execution of securityOn
method, window and door mocks recorded all interactions. This lets us verify that window and door objects were instructed to close themselves. That's all we need to test from SecurityCental
perspective.
You may ask how can we tell if door and window will be closed for real if we use mock? The answer is that we can’t. But we don’t care about it.
This is not responsibility of SecurityCentral
.
This is responsibility of Door
and Window
alone to close itself when they get proper signal. We can test it independently in different unit test.
public class SecurityCentral {
private final Window window;
private final Door door;
public SecurityCentral(Window window, Door door) {
this.window = window;
this.door = door;
}
void securityOn() {
window.close();
door.close();
}
}
public class SecurityCentralTest {
Window windowMock = mock(Window.class);
Door doorMock = mock(Door.class);
@Test
public void enabling_security_locks_windows_and_doors() {
SecurityCentral securityCentral = new SecurityCentral(windowMock, doorMock);
securityCentral.securityOn();
verify(doorMock).close();
verify(windowMock).close();
}
}
In summary, this code demonstrates a simple security system that can close windows and doors when enabled, and it includes a test to ensure that the functionality works as expected. The test uses mock objects to isolate the behavior of the SecurityCentral class and verify that the close() methods of the Window and Door classes are called when the security system is enabled. This helps ensure that the SecurityCentral class is working correctly and that any changes to the code in the future do not break the expected behavior.
The purpose of the SecurityCentralTest is to ensure that the SecurityCentral class is correctly interacting with the Door and Window classes by calling their close() methods when the security system is enabled. By using mock objects, we can focus on testing the behavior of the SecurityCentral class without worrying about the actual implementation of the Door and Window classes. This allows us to write more focused and isolated tests, making it easier to identify and fix issues in the code.
这里的解释,类比LogAnalyzer这个被测试类。IExtensionManger, StubExtensionManger和FileExtensionManager
我们关注的重点,是让LogAnalyzer的IsvalidLogFileName通过测试,而至于FileExtensionManager本身,是需要有其他的单元测试去负责的。