Skip to Content

Changes for page Testable Design

Last modified by chrisby on 2024/09/19 10:50
From version 3.8
edited by chrisby
on 2023/11/04 11:10
Change comment: There is no comment for this version
To version 3.9
edited by chrisby
on 2023/11/05 19:43
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -20,12 +20,3 @@
20 20   * Develop self-contained modules: Each module should be a self-contained unit of functionality. New features should be introduced by creating new modules.
21 21  * **Avoid the singleton design pattern** because its private constructor prevents mocking. Consider a `getInstance()` method that returns an interface type instead.
22 22  * **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.
23 -
24 -###
25 -
26 -### Testable Architecture
27 -
28 -An important part of a testable architecture is the **Humble Object Pattern**. The pattern emphasizes the isolation of complex to test aspects (such as GUI interactions), keeping them 'humble' with minimal logic:
29 -
30 -* **Minimize logic of hard-to-test layers** such as GUIs to keep them as thin as possible, focusing primarily on user interaction, routing, and data transformation.
31 -* **Maximize business logic**: You can move logic to the business logic/service layer, which is easier to test, improving overall testability.