Wiki source code of Mocking

Version 1.10 by chrisby on 2023/11/28 22:29

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