Changes for page Testable Design

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -8,16 +8,13 @@
8	8
9	9	* **Avoid direct instantiation of objects** in units being tested; doing so tightly couples the implementation and restricts substitutability. **Use factories** and **dependency injections** instead.
10	10	* **Avoid reflections** undermining encapsulation.
11		-* **Avoid method chaining**, which can make it difficult to replace module dependencies.
12		-* **Avoid using final and static methods**, as they cannot be overridden and reduce testability. This is especially important for methods that may require mocking.
13		-* **Keep private methods simple.** Their functionality should be tested indirectly through the public methods they call, rather than testing them directly. If it becomes too complex, extracting a separate class may be an option.
	11	+* **Keep private methods simple.** Their functionality should be tested indirectly through the public methods they call, rather than testing them directly. If it becomes too complex, extracting a separate class should be considered.
14	14	* **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.
15		-*
	13	+* **Avoid the singleton design pattern** because its private constructor prevents mocking. Consider a `getInstance()` method that returns an interface type instead.
16	16
17		-**Avoid the singleton design pattern** because its private constructor prevents mocking. Consider a `getInstance()` method that returns an interface type instead.
18		-
19	19	#### Patterns and Principles
20	20
	17	+* **Procedural code is harder to mock than object-oriented code.** So if mocks are required, the code should be object-oriented.
21	21	* **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.
22	22	* **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.
23	23	* **Create intermediate wrappers** with testable interfaces for better mockability when integrating third-party libraries and immutable, untestable code.
...	...	@@ -33,5 +33,4 @@
33	33	* 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.
34	34	* Injectable promotes decoupling. Dependency injection allows for more flexible and extensible code through interchangeable dependencies.
35	35	* **Favor dependency injection over service lookups.**
36		-
37		-####
	33	+* **Avoid method chaining**, which can make it difficult to replace a units dependencies.