Changes for page Mocking

Summary

• Page properties (2 modified, 0 added, 0 removed)

Details

Page properties

Syntax

...	...	@@ -1,1 +1,1 @@
1		-XWiki 2.1
	1	+Markdown 1.2

Content

...	...	@@ -1,12 +1,9 @@
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		-=== ===
	5	+### Benefits of Mocking
7	7
8		-=== Benefits of Mocking ===
9		-
10	10	* Isolation of units to test each unit separately, dramatically reducing complexity and increasing test execution speed by replacing loaded modules with mocks.
11	11	* Simplifies the re-creation of specific scenarios (use cases, boundary cases).
12	12	* Expose hidden internals of production code without compromising encapsulation.
...	...	@@ -13,11 +13,10 @@
13	13	* Injection of test-specific behaviors not present in production code.
14	14	* Enables the simulation of indirect dependencies by letting mocks return other mocks.
15	15
16		-=== ===
	13	+###
17	17
18		-=== Types of Mocks ===
	15	+### Types of Mocks
19	19
20		-(% style="text-align: justify;" %)
21	21	Stubs are by far the most common type of mock. Keep your tests as simple as possible. Make them more complex only when necessary.
22	22
23	23	* **Stubs**: Simplest form, returning a hardcoded value or providing an empty method body.
...	...	@@ -25,14 +25,14 @@
25	25	* **Spy**: Records internal data of the unit being tested when such data is not directly accessible.
26	26	* **Mock object**: Contains complex logic, simulates behaviors such as computation and exception handling, and can even run tests.
27	27
28		-=== ===
	24	+###
29	29
30		-=== Tips ===
	26	+### Tips
31	31
32	32	* **Mock third-party libraries in unit tests** to ensure proper unit functionality. However, they should not be mocked in component and integration tests.
33	33	* Aim for a **minimal number of dependencies in a unit** for easier testing and mocking:
34		-** 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.
35		-** Prefer many small classes/units to one large one for easier testing.
36		-** If a class has excessive dependencies, consider splitting it up or extracting some dependencies into a new class to create smaller, more cohesive units.
37		-** If a production class requires more than one test class, it's probably a sign that the class is too large.
38		-** 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.