A testing standard that prioritizes signal over coverage, architecture over assertion, and clarity over volume.
Test suites grow. They accumulate. A method gets written, a test gets written. Multiply by months of development and you have thousands of lines of test code—more than you can reason about, more than you can maintain, more than you can trust.
When a test fails and your response is to adjust the assertion until it passes, the test isn't protecting anything. It's encoding state.
MTMT is a call for fewer tests—each one earning its place by providing meaningful protection against real failure modes.
SPECIFICATION.md defines:
- Part I: Testing Philosophy — Principles for deciding what to test
- Part II: Testing Structure — Recommended organization for test files (optional)
For the rationale and full argument, see the Manifesto.
- Copy
SPECIFICATION.mdinto your project (asTESTING.mdor similar) - Preserve Part I (Testing Philosophy) unchanged
- Customize Part II's designated slots: boundaries table, test placement guide, and conventions
- Keep the version reference (
v0.1.0) to indicate which iteration you follow
Part I defines the testing philosophy and must be preserved for MTMT compliance. Part II provides a structural framework with designated customization points for your project's specific boundaries.
| Principle | Meaning |
|---|---|
| Signal over coverage | Prioritize tests that catch real problems over tests that execute code |
| Trust the architecture | Don't test what types, factories, and constraints already prevent |
| Test at boundaries | Focus on system entry points, exit points, and integration seams |
| Regression-driven growth | Write targeted tests in response to actual bugs |
| Complexity as feedback | Extensive testing needs may indicate code that should be simplified |
| Intentional gaps | Untested code should have structural justification |
Scale: The flat structure in Part II is designed for small-to-medium projects with well-defined boundaries. Large projects with many boundaries may need to adapt the organizational approach. Part II is optional for this reason.
If you'd like to indicate adoption:
[](https://github.com/seanbrar/minimal-tests-maximum-trust)
See how the specification has been adapted:
- Pollux (repo) — GSoC 2025 project, original application
- paperweight (repo) — arXiv research paper summarizer
This specification uses Semantic Versioning:
- MAJOR: Breaking changes to core principles
- MINOR: New guidance, clarifications, additions
- PATCH: Typos, formatting, minor wording improvements
See CHANGELOG.md for version history.
Feedback and suggestions are welcome. Open an issue to discuss proposed changes before submitting a pull request.
Changes that affect the meaning of core principles are considered breaking changes (see Versioning).
CC0 1.0 Universal — Public domain. Use however you like.