Object-Oriented: While both procedural and functional programming paradigms can be tested, they often face a scalability problem. As the complexity of the system increases, testing isolated segments of code becomes increasingly difficult. One solution is to encapsulate this complex logic in an object-oriented hierarchy of classes. These classes can encapsulate the code and its associated complexity behind dependencies, creating isolated units that can be easily tested. The same procedural or functional code can easily be wrapped in classes, allowing object-oriented programming to combine the benefits of all programming paradigms. It's worth noting that for any code base that reaches a certain level of complexity, adopting an object-oriented approach can significantly improve its testability.
Classes implement interfaces: The class implements a well-designed interface, just as large as necessary to satisfy its requirements.
Tests run against interfaces, so the implementations details are not relevant as long as the results are correct.
Minimal number of dependencies in a unit for low complexity.
Dependencies are injectable via constructor injection or setter injection. 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.
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 reliance on abstractions, not concretions.
Additional Details
Minimization of direct instantiation of objects in units being tested; doing so tightly couples the implementation and restricts substitutability.
Favor factories and dependency injection over service lookups.
Avoid reflections undermining encapsulation.
Avoid method chaining, which can make it difficult to replace module dependencies.
Avoid using final and static methods, as they cannot be overridden and reduce testability. This is especially important for methods that may require mocking.
Keep private methods simple. Their functionality should be tested indirectly through the public methods that call them, not directly.
No business logic in constructors and static initialization blocks. Unnecessary logic could be inadvertently executed, or unexpected side effects could occur when a subclass calls the superclass constructor. Instead, place this logic in methods or other objects that can be replaced.
For third-party libraries and immutable, untestable code, create intermediate wrappers with testable interfaces for better mockability.
Modular design:
Create distinct, small modules, each with unique functionality and responsibilities. This ensures that changes in one module are isolated from others.
Maintain loose coupling: Minimize the dependencies between modules.
Develop self-contained modules: Each module should be a self-contained unit of functionality. New features should be introduced by creating new modules.
Avoid the singleton design pattern because its private constructor prevents mocking. Consider a getInstance() method that returns an interface type instead.
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.
