Skip to Content

Changes for page Mocking

Last modified by chrisby on 2023/11/28 22:32
From version 1.11
edited by chrisby
on 2023/11/28 22:29
Change comment: Update property syntax
To version 1.1
edited by chrisby
on 2023/05/29 11:37
Change comment: There is no comment for this version

Summary

Details

Page properties
Parent
... ... @@ -1,1 +1,1 @@
1 -Software Engineering.Testing.WebHome
1 +Software Architecture.Testing.WebHome
Syntax
... ... @@ -1,1 +1,1 @@
1 -Markdown 1.2
1 +XWiki 2.1
Content
... ... @@ -1,9 +1,11 @@
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 6  
7 +=== Benefits of Mocking ===
8 +
7 7  * Isolation of units to test each unit separately, dramatically reducing complexity and increasing test execution speed by replacing loaded modules with mocks.
8 8  * Simplifies the re-creation of specific scenarios (use cases, boundary cases).
9 9  * Expose hidden internals of production code without compromising encapsulation.
... ... @@ -10,25 +10,21 @@
10 10  * Injection of test-specific behaviors not present in production code.
11 11  * Enables the simulation of indirect dependencies by letting mocks return other mocks.
12 12  
13 -###
14 14  
15 -### Types of Mocks
16 +=== Types of Mocks ===
16 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 -* **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**: 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.
20 +* Stubs: Simplest form, returning a hardcoded value or providing an empty method body.
21 +* Fake object: Include minimal logic to handle different case scenarios.
22 +* Spy: Injected to capture interaction data with fake objects when such data is not directly accessible.
23 +* Mock objects: Contain complex logic, simulate behaviors such as computation and exception handling, and even run tests.
23 23  
24 -###
25 25  
26 -### Tips
26 +=== Tips ===
27 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.
29 -* Aim for a **minimal number of dependencies in a unit** for easier testing and mocking:
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.
28 +* Mock third-party libraries for unit tests to ensure proper unit functionality. Instead, use the third-party libraries in component and integration tests.
29 +* Minimize the dependencies of a unit. The fewer dependencies, the easier it is to mock and test the logic.
30 +** 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.
31 +** If there is more than one test class for a production class, the production class is probably too large.
32 +** If the test code is very complex and hard to understand, the production class is probably too large.