Changes for page Mocking

Summary

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

Details

Page properties

Parent

...	...	@@ -1,1 +1,1 @@
1		-Software Engineering.Testing.WebHome
	1	+Software Architecture.Testing.WebHome

Content

...	...	@@ -3,8 +3,6 @@
3	3	* Mocking simplifies unit testing by replacing the dependencies of the unit being tested with simplified, simulated versions called mocks.
4	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.
5	5
6		-=== ===
7		-
8	8	=== Benefits of Mocking ===
9	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.
...	...	@@ -13,26 +13,20 @@
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		-=== ===
17		-
18	18	=== Types of Mocks ===
19	19
20	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		-* **Stubs**: Simplest form, returning a hardcoded value or providing an empty method body.
24		-* **Fake object**: Include minimal logic to handle different case scenarios.
25		-* **Spy**: Records internal data of the unit being tested when such data is not directly accessible.
26		-* **Mock object**: Contains complex logic, simulates behaviors such as computation and exception handling, and can 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.
27	27
28		-=== ===
29		-
30	30	=== Tips ===
31	31
32		-* **Mock third-party libraries in unit tests** to ensure proper unit functionality. Instead, use these libraries in component and integration tests.
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.
	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.