| ... | ... | @@ -1,9 +1,8 @@ | 
              
                    | 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. | 
              
                    | 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. | 
              
                    |  | 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. | 
              
                    | 5 | 5 |  | 
              
                    | 6 |  | - ===Benefits of Mocking === | 
              
                    |  | 5 | +### 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. | 
              
                    | 9 | 9 | * Simplifies the re-creation of specific scenarios (use cases, boundary cases). | 
                      
        | ... | ... | @@ -11,22 +11,25 @@ | 
              
                    | 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 |  | - ===Types of Mocks === | 
              
                    |  | 13 | +### | 
              
                    | 15 | 15 |  | 
              
                    | 16 |  | -(% style="text-align: justify;" %) | 
              
                    |  | 15 | +### Types of Mocks | 
              
                    |  | 16 | + | 
              
                    | 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 | 19 | * **Stubs**: Simplest form, returning a hardcoded value or providing an empty method body. | 
              
                    | 20 | 20 | * **Fake object**: Include minimal logic to handle different case scenarios. | 
              
                    | 21 |  | -* **Spy**: Injected to captureinteraction datawith fakeobjects when such data is not directly accessible. | 
              
                    | 22 |  | -* **Mock object s**: Contain complex logic, simulate behaviors such as computation and exception handling, and even run tests. | 
              
                    |  | 21 | +* **Spy**: Records internal data of the unit being tested when such data is not directly accessible. | 
              
                    |  | 22 | +* **Mock object**: Contains complex logic, simulates behaviors such as computation and exception handling, and can even run tests. | 
              
                    | 23 | 23 |  | 
              
                    | 24 |  | - ===Tips === | 
              
                    |  | 24 | +### | 
              
                    | 25 | 25 |  | 
              
                    | 26 |  | -* **Mock third-party libraries for unit tests** to ensure proper unit functionality. Instead, use these libraries in component and integration tests. | 
              
                    |  | 26 | +### Tips | 
              
                    |  | 27 | + | 
              
                    |  | 28 | +* **Mock third-party libraries in unit tests** to ensure proper unit functionality. However, they should not be mocked 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. | 
              
                    |  | 30 | +    * 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. | 
              
                    |  | 31 | +    * Prefer many small classes/units to one large one for easier testing. | 
              
                    |  | 32 | +    * If a class has excessive dependencies, consider splitting it up or extracting some dependencies into a new class to create smaller, more cohesive units. | 
              
                    |  | 33 | +    * If a production class requires more than one test class, it's probably a sign that the class is too large. | 
              
                    |  | 34 | +    * Overly complex test code may indicate an overly large production class. |