Skip to Content

Wiki source code of Mocking

Version 1.4 by chrisby on 2023/05/29 12:21
Hide last authors
chrisby 1.1 1 === Purpose ===
2
3 * Mocking simplifies unit testing by replacing the dependencies of the unit being tested with simplified, simulated versions called mocks.
4 * Example: Consider a unit under test that relies on a database. In testing, the database can be mocked to return a static value, eliminating the need for an actual database.
5
6 === Benefits of Mocking ===
7
8 * Isolation of units to test each unit separately, dramatically reducing complexity and increasing test execution speed by replacing loaded modules with mocks.
9 * Simplifies the re-creation of specific scenarios (use cases, boundary cases).
10 * Expose hidden internals of production code without compromising encapsulation.
11 * Injection of test-specific behaviors not present in production code.
12 * Enables the simulation of indirect dependencies by letting mocks return other mocks.
13
14 === Types of Mocks ===
15
chrisby 1.2 16 (% style="text-align: justify;" %)
chrisby 1.1 17 Stubs are by far the most common type of mock. Keep your tests as simple as possible. Make them more complex only when necessary.
18
chrisby 1.3 19 * **Stubs**: Simplest form, returning a hardcoded value or providing an empty method body.
20 * **Fake object**: Include minimal logic to handle different case scenarios.
21 * **Spy**: Injected to capture interaction data with fake objects when such data is not directly accessible.
22 * **Mock objects**: Contain complex logic, simulate behaviors such as computation and exception handling, and even run tests.
chrisby 1.1 23
24 === Tips ===
25
chrisby 1.4 26 * **Mock third-party libraries for unit tests** to ensure proper unit functionality. Instead, use these libraries in component and integration tests.
chrisby 1.3 27 * Aim for a **minimal number of dependencies in a unit** for easier testing and mocking:
28 ** Limit dependencies in a unit in a similar way to the best practices for function arguments: the fewer the better, with an absolute maximum of three.
29 ** Prefer many small classes/units to one large one for easier testing.
30 ** If a class has excessive dependencies, consider splitting it up or extracting some dependencies into a new class to create smaller, more cohesive units.
31 ** If a production class requires more than one test class, it's probably a sign that the class is too large.
32 ** Overly complex test code may indicate an overly large production class.