Changes for page Testable Design

Summary

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

Details

Page properties

Content

...	...	@@ -1,31 +1,37 @@
1	1	### What Makes Code Testable?
2	2
3		-* **Object-Oriented**: Although both procedural and functional programming paradigms support testing, managing test complexity can become a challenge as the system scales. As complexity increases, maintaining test isolation becomes more difficult. An effective strategy is to use object-oriented techniques that encapsulate complex logic within hierarchies of classes, creating testable units that hide their internal complexity behind interfaces. Wrapping procedural or functional code in classes can combine the strengths of several paradigms. Any code base that reaches a certain level of complexity can benefit from an object-oriented approach to improve testability.
4		-* **Minimal number of dependencies** in a unit for low complexity.
5		-* **Dependencies are injectable** via [[constructor injection or setter injection|doc:Software Engineering.Architecture.Dependency Injection.Types of Dependency Injection.WebHome]].
6		- * Injectable is equivalent to mockable. Mocks make testing with dependencies much easier. IoC containers are good tools for building many applications consisting of classes into which dependencies need to be injected.
7		- * Injectable promotes decoupling. Dependency injection allows for more flexible and extensible code through interchangeable dependencies.
8		-* **Outsource code that is difficult to test.** For example, network connections to external services should not be part of unit or component tests and should therefore be mocked away.
9		-* **Avoid direct instantiation of objects** in units being tested; doing so tightly couples the implementation and restricts substitutability. Use **factories** and **dependency injections** instead.
10		-* **Favor dependency injection over service lookups.**
	3	+#### Object-Oriented Programming
	4	+
	5	+Although both procedural and functional programming paradigms support testing, managing test complexity can become a challenge as the system scales. As complexity increases, maintaining test isolation becomes more difficult. An effective strategy is to use object-oriented techniques that encapsulate complex logic within hierarchies of classes, creating testable units that hide their internal complexity behind interfaces. Wrapping procedural or functional code in classes can combine the strengths of several paradigms. Any code base that reaches a certain level of complexity can benefit from an object-oriented approach to improve testability.
	6	+
	7	+#### Object Structure
	8	+
	9	+* **Avoid direct instantiation of objects** in units being tested; doing so tightly couples the implementation and restricts substitutability. **Use factories** and **dependency injections** instead.
11	11	* **Avoid reflections** undermining encapsulation.
12	12	* **Avoid method chaining**, which can make it difficult to replace module dependencies.
13	13	* **Avoid using final and static methods**, as they cannot be overridden and reduce testability. This is especially important for methods that may require mocking.
14		-* **Keep private methods simple.** Their functionality should be tested indirectly through the public methods that call them, not directly.
	13	+* **Keep private methods simple.** Their functionality should be tested indirectly through the public methods they call, rather than testing them directly. If it becomes too complex, extracting a separate class may be an option.
15	15	* **No business logic in constructors and static initialization blocks.** Unnecessary logic could be inadvertently executed, or unexpected side effects could occur when a subclass calls the superclass constructor. Instead, place this logic in methods or other objects that can be replaced.
16		-* For third-party libraries and immutable, untestable code, create **intermediate wrappers with testable interfaces** for better mockability.
	15	+*
	16	+
	17	+**Avoid the singleton design pattern** because its private constructor prevents mocking. Consider a `getInstance()` method that returns an interface type instead.
	18	+
	19	+#### Patterns and Principles
	20	+
	21	+* **Favor composition over inheritance.** Use inheritance only for polymorphism, as it is less flexible than composition. Composition should be the primary approach to code reuse.
	22	+* **Outsource code that is difficult to test.** For example, network connections to external services should not be part of unit or component tests and should therefore be mocked away.
	23	+* **Create intermediate wrappers** with testable interfaces for better mockability when integrating third-party libraries and immutable, untestable code.
17	17	* **Modular design**:
18	18	* Create distinct, small modules, each with unique functionality and responsibilities. This ensures that changes in one module are isolated from others.
19	19	* Maintain loose coupling: Minimize the dependencies between modules.
20	20	* Develop self-contained modules: Each module should be a self-contained unit of functionality. New features should be introduced by creating new modules.
21		-* **Avoid the singleton design pattern** because its private constructor prevents mocking. Consider a `getInstance()` method that returns an interface type instead.
22		-* **Favor composition over inheritance.** Use inheritance only for polymorphism, as it is less flexible than composition. Composition should be the primary approach to code reuse.
23	23
24		-###
	29	+#### Dependency Management
25	25
26		-### Testable Architecture
	31	+* **Low number of dependencies** in a unit for low complexity.
	32	+* **Dependencies are injectable** via [[constructor injection or setter injection|doc:Software Engineering.Architecture.Dependency Injection.Types of Dependency Injection.WebHome]].
	33	+ * Injectable is equivalent to mockable. Mocks make testing with dependencies much easier. IoC containers are good tools for building many applications consisting of classes into which dependencies need to be injected.
	34	+ * Injectable promotes decoupling. Dependency injection allows for more flexible and extensible code through interchangeable dependencies.
	35	+* **Favor dependency injection over service lookups.**
27	27
28		-An important part of a testable architecture is the **Humble Object Pattern**. The pattern emphasizes the isolation of complex to test aspects (such as GUI interactions), keeping them 'humble' with minimal logic:
29		-
30		-* **Minimize logic of hard-to-test layers** such as GUIs to keep them as thin as possible, focusing primarily on user interaction, routing, and data transformation.
31		-* **Maximize business logic**: You can move logic to the business logic/service layer, which is easier to test, improving overall testability.
	37	+####