Testability risk

What it means

Testability risk rises when behavior depends on hidden state, timing, external services, nondeterministic inputs, or broad setup. It can also arise when tests are slow or flaky enough that developers avoid them. The risk should identify which behavior is hard to validate and what evidence is missing.

Example

A retry policy depends on real time and a live queue, making edge cases slow to reproduce. A controllable clock and test queue reduce the risk while preserving an integration test for the real connection.

Limitations

A fully mocked test suite may appear easy to run while missing integration defects. Testability improvements can also increase abstraction cost. Review fidelity, speed, and failure diagnosis together.

How to use the signal

Separate unit-test convenience from system fidelity, and retain integration evidence for behavior that mocks cannot represent.

Weave can connect testability risk with test feedback time, flaky tests, and rework. Use the test system to validate behavior and Weave to identify workflow friction.