Skip to Content

Changes for page Testable Design

Last modified by chrisby on 2024/09/19 10:50
From version 1.9
edited by chrisby
on 2023/06/03 15:35
Change comment: There is no comment for this version
To version 1.11
edited by chrisby
on 2023/06/03 15:36
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -28,6 +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 31  
32 32  === Testable Architecture ===
33 33  
... ... @@ -34,5 +34,5 @@
34 34  An important part of a testable architecture is the **Humble Object Pattern**:
35 35  
36 36  * The pattern emphasizes the isolation of complex to test aspects (such as GUI interactions), keeping them 'humble' with minimal logic.
37 -* **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.
38 38  * **Maximize business logic**: Where possible, move logic to the business logic/service layer, which is easier to test, improving overall testability.