tomevault-io Testability Assessment
Evaluate whether code can be effectively unit tested in isolation.
Layers:
rules.md- Quick reference and severity guidanceexamples.md- Detailed code examples
Quick Reference
| Factor | Question | Severity if problematic |
|---|---|---|
| Dependency injection | Are deps passed in? | High |
| Global state | Is shared state avoided? | High |
| Pure functions | Is logic separated from I/O? | Medium |
| Time/randomness | Are these injectable? | Medium |
| File system | Can it be abstracted? | Medium |
| Seams | Can behavior be substituted? | Medium-High |
| Observability | Can you assert on outputs? | Medium |
| Mock avoidance | Does the design eliminate the need for mocking? | High |
Quick Heuristic
If testing a function requires:
- 0 mocks: Excellent testability (pure function)
- 1-2 mocks: Acceptable (clear external boundaries only)
- 3-5 mocks: Redesign required (too many responsibilities or mocking internal code)
- 6+ mocks: Design failure (refactor before writing tests)
If any mock or monkeypatch.setattr targets internal functions, methods, or classes rather than external boundaries, the count is irrelevant -- redesign for testability instead.
For rules: see rules.md
For examples: see examples.md
Converted and distributed by TomeVault — claim your Tome and manage your conversions.