Hide last authors
| author | version | line-number | content |
|---|---|---|---|
 |
1.11 | 1 | ### Purpose |
| |
1.1 | 2 | |
| |
1.10 | 3 | * **Mocking simplifies unit testing by replacing the dependencies** of the unit being tested with simplified, simulated versions called mocks. 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. |
| |
1.1 | 4 | |
| |
1.11 | 5 | ### Benefits of Mocking |
| |
1.6 | 6 | |
| |
1.12 | 7 | * **Isolation of units** to test each unit separately, dramatically reducing complexity and increasing test execution speed by replacing loaded modules with mocks. |
| 8 | * **Simplifies the re-creation of specific scenarios** (use cases, boundary cases) in which a dependency behaves in a particular way. | ||
| 9 | * **Expose hidden internals** of production code without compromising encapsulation. | ||
| 10 | * **Injection of test-specific behaviors** not present in production code. | ||
| 11 | * **Enables the simulation of indirect dependencies** by letting mocks return other mocks. | ||
| |
1.1 | 12 | |
| |
1.11 | 13 | ### Types of Mocks |
| |
1.1 | 14 | |
| 15 | Stubs are by far the most common type of mock. Keep your tests as simple as possible. Make them more complex only when necessary. | ||
| 16 | |||
| |
1.3 | 17 | * **Stubs**: Simplest form, returning a hardcoded value or providing an empty method body. |
| 18 | * **Fake object**: Include minimal logic to handle different case scenarios. | ||
| |
1.7 | 19 | * **Spy**: Records internal data of the unit being tested when such data is not directly accessible. |
| 20 | * **Mock object**: Contains complex logic, simulates behaviors such as computation and exception handling, and can even run tests. | ||
| |
1.1 | 21 | |
| |
1.12 | 22 | ### |
| |
1.6 | 23 | |
| |
1.11 | 24 | ### Tips |
| |
1.1 | 25 | |
| |
1.9 | 26 | * **Mock third-party libraries in unit tests** to ensure proper unit functionality. However, they should not be mocked in component and integration tests. |
| |
1.3 | 27 | * Aim for a **minimal number of dependencies in a unit** for easier testing and mocking: |
| |
1.11 | 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. |