| ... |
... |
@@ -16,17 +16,15 @@ |
| 16 |
16 |
(% style="text-align: justify;" %) |
| 17 |
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 |
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. |
|
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 |
23 |
|
| 24 |
24 |
=== Tips === |
| 25 |
25 |
|
| 26 |
|
-* **Mock third-party libraries in unit tests** to ensure proper unit functionality. Instead, use these libraries in component and integration tests. |
| 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. |
|
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. |
