Changes for page Testable Design

Summary

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

Details

Page properties

Content

...	...	@@ -2,7 +2,7 @@
2	2
3	3	=== Core aspects ===
4	4
5		-* **Object-Oriented**: While both procedural and functional programming paradigms can be tested, they often face a scalability problem. As the complexity of the system increases, testing isolated segments of code becomes increasingly difficult. One solution is to encapsulate this complex logic in an object-oriented hierarchy of classes. These classes can encapsulate the code and its associated complexity behind dependencies, creating isolated units that can be easily tested. The same procedural or functional code can easily be wrapped in classes, allowing to combine the benefits of all programming paradigms. It's worth noting that for any code base that reaches a certain level of complexity, adopting an object-oriented approach can significantly improve its testability.
	5	+* **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.
6	6	* **Classes implement interfaces**: The class implements a well-designed interface, just as large as necessary to satisfy its requirements.
7	7	* **Tests run against interfaces**, so the implementations details are not relevant as long as the results are correct.
8	8	* **Minimal number of dependencies** in a unit for low complexity.
...	...	@@ -9,9 +9,11 @@
9	9	* **Dependencies are injectable** via [[constructor injection or setter injection>>doc:Software Architecture.Dependency Injection.Types of Dependency Injection.WebHome]]. 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.
10	10	* **Dependencies are interfaces** that can be implemented as 'mocks' for testing purposes, thus enabling the independent, concurrent development of software units. This aligns with the Dependency Inversion Principle (DIP), which promotes reliance on abstractions, not concretions.
11	11
	12	+=== ===
	13	+
12	12	=== Additional Details ===
13	13
14		-* **Minimization of direct instantiation of objects** in units being tested; doing so tightly couples the implementation and restricts substitutability. Use **factories** and **dependency injections** instead.
	16	+* **Avoid direct instantiation of objects** in units being tested; doing so tightly couples the implementation and restricts substitutability. Use **factories** and **dependency injections** instead.
15	15	* **Favor dependency injection over service lookups.**
16	16	* **Avoid reflections** undermining encapsulation.
17	17	* **Avoid method chaining**, which can make it difficult to replace module dependencies.