Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 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 | |||
| 16 | (% style="text-align: justify;" %) | ||
| 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 | |||
| 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. | ||
| 23 | |||
| 24 | === Tips === | ||
| 25 | |||
| 26 | * Mock third-party libraries for unit tests to ensure proper unit functionality. Instead, use the third-party libraries in component and integration tests. | ||
| 27 | * Minimize the dependencies of a unit. The fewer dependencies, the easier it is to mock and test the logic. | ||
| 28 | ** If a class has too many dependencies, split the class or extract two dependencies into a new class. This also results in smaller, more cohesive classes/units. | ||
| 29 | ** If there is more than one test class for a production class, the production class is probably too large. | ||
| 30 | ** If the test code is very complex and hard to understand, the production class is probably too large. |