... |
... |
@@ -1,8 +1,8 @@ |
1 |
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 |
|
- |
6 |
6 |
=== Benefits of Mocking === |
7 |
7 |
|
8 |
8 |
* Isolation of units to test each unit separately, dramatically reducing complexity and increasing test execution speed by replacing loaded modules with mocks. |
... |
... |
@@ -11,8 +11,6 @@ |
11 |
11 |
* Injection of test-specific behaviors not present in production code. |
12 |
12 |
* Enables the simulation of indirect dependencies by letting mocks return other mocks. |
13 |
13 |
|
14 |
|
-=== === |
15 |
|
- |
16 |
16 |
=== Types of Mocks === |
17 |
17 |
|
18 |
18 |
(% style="text-align: justify;" %) |
... |
... |
@@ -20,14 +20,12 @@ |
20 |
20 |
|
21 |
21 |
* **Stubs**: Simplest form, returning a hardcoded value or providing an empty method body. |
22 |
22 |
* **Fake object**: Include minimal logic to handle different case scenarios. |
23 |
|
-* **Spy**: Records internal data of the unit being tested when such data is not directly accessible. |
24 |
|
-* **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. |
25 |
25 |
|
26 |
|
-=== === |
27 |
|
- |
28 |
28 |
=== Tips === |
29 |
29 |
|
30 |
|
-* **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 in unit tests** to ensure proper unit functionality. Instead, use these libraries in component and integration tests. |
31 |
31 |
* Aim for a **minimal number of dependencies in a unit** for easier testing and mocking: |
32 |
32 |
** 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. |
33 |
33 |
** Prefer many small classes/units to one large one for easier testing. |