2.4Pushing Back on Untestable Designs

Sometimes a proposed design makes testing impractical. Pushing back is necessary but must be done diplomatically.

Signs of an Untestable Design

• No way to inject test data or mock dependencies
• Side effects that cannot be observed or verified
• Tight coupling between components that prevents isolated testing
• Race conditions baked into the architecture
• No clear boundaries between units of functionality
• Configuration that differs so significantly between environments that test results are meaningless

The Diplomatic Pushback Pattern

Step 1: Acknowledge the design's strengths.

"The event-driven approach is a great fit for this use case -- it gives us the decoupling we need."

Step 2: Raise the testing concern as a question.

"One thing I want to make sure we plan for: how will we verify that events are processed in the correct order? In async systems, I have seen ordering issues that are nearly impossible to reproduce in tests."

Step 3: Propose a concrete alternative or addition.

"Could we add a correlation ID to each event and build a test harness that traces the full event chain? That would let us write deterministic integration tests."

Step 4: Quantify the cost of not addressing it.

"Without this, we would be relying on manual testing with timing-dependent reproduction steps. Based on similar features, that typically means 2-3 production incidents before we identify and fix the edge cases."

What Not to Do

• Do not say "this is untestable" without offering an alternative
• Do not block the discussion by insisting on perfection -- suggest improvements that can be phased in
• Do not frame testability as QA's problem -- frame it as a product quality problem