Skip to Content

Changes for page Testable Design

Last modified by chrisby on 2024/09/19 10:50
From version 1.11
edited by chrisby
on 2023/06/03 15:36
Change comment: There is no comment for this version
To version 2.1
edited by chrisby
on 2023/06/04 10:13
Change comment: Renamed back-links.

Summary

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