| ... |
... |
@@ -1,32 +1,32 @@ |
| 1 |
|
-### Purpose |
|
1 |
+=== Purpose === |
| 2 |
2 |
|
| 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. |
|
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. |
| 4 |
4 |
|
| 5 |
|
-### Benefits of Mocking |
|
6 |
+=== Benefits of Mocking === |
| 6 |
6 |
|
| 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. |
|
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. |
| 12 |
12 |
|
| 13 |
|
-### Types of Mocks |
|
14 |
+=== Types of Mocks === |
| 14 |
14 |
|
|
16 |
+(% style="text-align: justify;" %) |
| 15 |
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 |
16 |
|
| 17 |
17 |
* **Stubs**: Simplest form, returning a hardcoded value or providing an empty method body. |
| 18 |
18 |
* **Fake object**: Include minimal logic to handle different case scenarios. |
| 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. |
|
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. |
| 21 |
21 |
|
| 22 |
|
-### |
|
24 |
+=== Tips === |
| 23 |
23 |
|
| 24 |
|
-### Tips |
| 25 |
|
- |
| 26 |
|
-* **Mock third-party libraries in unit tests** to ensure proper unit functionality. However, they should not be mocked in component and integration tests. |
|
26 |
+* **Mock third-party libraries** for unit tests to ensure proper unit functionality. Instead, use these libraries in component and integration tests. |
| 27 |
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. |
|
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. |
