8.2Testability as a Design Principle

Anti-Pattern: The system is built first, then QA tries to test it. Testing is hard because services are tightly coupled, behavior is non-deterministic, and there is no way to observe internal state.

Pattern: Testability is a design requirement, considered during architecture reviews alongside performance, security, and scalability.

Three Pillars of Testability

Dependency injection — Services accept their dependencies as parameters rather than creating them internally. This allows tests to substitute real databases, APIs, and services with controlled test doubles. Without dependency injection, integration tests require the entire production stack.

Observability — The system exposes enough information for tests to verify behavior without reaching into internal state. Structured logging, event streams, and test hooks provide visibility into what the system did and why. If you cannot observe it, you cannot test it.

Determinism — Given the same inputs, the system produces the same outputs. Non-deterministic behavior (random values, wall-clock time, unordered collections) creates flaky tests. Design for determinism: inject clocks and random seeds, sort outputs when order does not matter, use stable identifiers.