Changes for page Testable Design

Summary

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

Details

Page properties

Content

...	...	@@ -6,10 +6,10 @@
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		-* **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.
	9	+* **Dependencies are injectable** via [[constructor injection or setter injection>>doc:Software Engineering.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		-=== ===
	12	+=== ===
13	13
14	14	=== Additional Details ===
15	15
...	...	@@ -28,7 +28,7 @@
28	28	* **Avoid the singleton design pattern** because its private constructor prevents mocking. Consider a getInstance() method that returns an interface type instead.
29	29	* **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.
30	30
31		-=== ===
	31	+=== ===
32	32
33	33	=== Testable Architecture ===
34	34
...	...	@@ -35,5 +35,5 @@
35	35	An important part of a testable architecture is the **Humble Object Pattern**:
36	36
37	37	* The pattern emphasizes the isolation of complex to test aspects (such as GUI interactions), keeping them 'humble' with minimal logic.
38		-* **Minimize complex layers**: Keep complex layers such as GUIs and adapters as thin as possible, focusing mainly on interaction and routing.
	38	+* **Minimize complex layers**: Keep complex layers such as GUIs and adapters as thin as possible, focusing mainly on user interaction and routing.
39	39	* **Maximize business logic**: Where possible, move logic to the business logic/service layer, which is easier to test, improving overall testability.