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.9
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,12 @@
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 +=== Testable Architecture ===
33 +
34 +An important part of a testable architecture is the **Humble Object Pattern**:
35 +
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 +* **Maximize business logic**: Where possible, move logic to the business logic/service layer, which is easier to test, improving overall testability.