minimal-testinglisted

# Minimal Testing ## Overview Build the change first. Then write the fewest tests that prove it works. Then prove each test can fail. **Core principle:** A test earns its place only if it fails when the change it covers is broken. Everything else is weight the codebase carries forever. Test-first development is not required here, because it grew suites where most of the code was tests. Those suites were slow to run, painful to refactor, and their failures rarely meant a user-visible break. ## The Workflow 1. **Implement the change.** Explore freely. Nothing gets deleted for being written before its test. 2. **Name the contract.** A contract is what the feature promises, what the bug report says is broken, or what the issue asks for. List its behaviors in one or two lines each. 3. **Write one test per contract behavior.** Add a test for a corner case only when you can name the real caller and the real input that reaches it. 4. **Prove each test bites.** Break the change: revert the fix, or remove the line that implements the behavior. Run the test and confirm it FAILS for the expected reason. Restore the change and confirm it PASSES. A test that passes against broken code proves nothing, so delete or fix it. 5. **Stop.** Do not add tests "to be thorough". ## What to Test | Work | Minimum set | |------|-------------| | Feature | One test per behavior in the contract, run through the public entry point a caller uses. | | Bug fix | One regression test