Wiki source code of Mocking

Version 1.9 by chrisby on 2023/06/18 10:55

version	line-number	content
1.1	1	=== Purpose ===
	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.
	5
1.6	6	=== ===
	7
1.1	8	=== Benefits of Mocking ===
	9
	10	* Isolation of units to test each unit separately, dramatically reducing complexity and increasing test execution speed by replacing loaded modules with mocks.
	11	* Simplifies the re-creation of specific scenarios (use cases, boundary cases).
	12	* Expose hidden internals of production code without compromising encapsulation.
	13	* Injection of test-specific behaviors not present in production code.
	14	* Enables the simulation of indirect dependencies by letting mocks return other mocks.
	15
1.6	16	=== ===
	17
1.1	18	=== Types of Mocks ===
	19
1.2	20	(% style="text-align: justify;" %)
1.1	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
1.3	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.
1.7	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.
1.1	27
1.6	28	=== ===
	29
1.1	30	=== Tips ===
	31
1.9	32	* Mock third-party libraries in unit tests to ensure proper unit functionality. However, they should not be mocked in component and integration tests.
1.3	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.