Skip to Content

Changes for page Testable Design

Last modified by chrisby on 2024/09/19 10:50
From version 3.2
edited by chrisby
on 2023/06/24 10:34
Change comment: There is no comment for this version
To version 3.4
edited by chrisby
on 2023/10/11 14:51
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -3,11 +3,11 @@
3 3  === Core aspects ===
4 4  
5 5  * **Object-Oriented**: Although both procedural and functional programming paradigms support testing, managing test complexity can become a challenge as the system scales. As complexity increases, maintaining test isolation becomes more difficult. An effective strategy is to use object-oriented techniques that encapsulate complex logic within hierarchies of classes, creating testable units that hide their internal complexity behind interfaces. Wrapping procedural or functional code in classes can combine the strengths of several paradigms. Any code base that reaches a certain level of complexity can benefit from an object-oriented approach to improve testability.
6 -* **Classes implement interfaces**: The class implements a well-designed interface, just as large as necessary to satisfy its requirements.
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 Engineering.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.
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 dependency on abstractions, not concretions.
7 +* **Dependencies are injectable** via [[constructor injection or setter injection>>doc:Software Engineering.Architecture.Dependency Injection.Types of Dependency Injection.WebHome]].
8 +** 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 +** Injectable promotes decoupling. Dependency injection allows for more flexible and extensible code through interchangeable dependencies.
10 +* **Outsource code that is difficult to test.** For example, network connections to external services should not be part of unit or component tests and should therefore be mocked away.
11 11  
12 12  === ===
13 13  
... ... @@ -32,8 +32,7 @@
32 32  
33 33  === Testable Architecture ===
34 34  
35 -An important part of a testable architecture is the **Humble Object Pattern**:
35 +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:
36 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 user 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.
37 +* **Minimize the logic of hard-to-test layers** such as GUIs and adapters to keep them as thin as possible, focusing primarily on user interaction, routing, and data transformation.
38 +* **Maximize business logic**: Where reasonably possible, move logic to the business logic/service layer, which is easier to test, improving overall testability.