Skip to Content

Changes for page Testable Design

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

Summary

Details

Page properties
Content
... ... @@ -27,3 +27,13 @@
27 27  ** Develop self-contained modules: Each module should be a self-contained unit of functionality. New features should be introduced by creating new modules.
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 +
31 +=== ===
32 +
33 +=== Testable Architecture ===
34 +
35 +An important part of a testable architecture is the **Humble Object Pattern**:
36 +
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.
39 +* **Maximize business logic**: Where possible, move logic to the business logic/service layer, which is easier to test, improving overall testability.