Pragmatic Testing

Tests exist to give confidence the system works — not to hit coverage metrics.

Before writing anything

Read 2–3 existing test files. Mirror the framework, file naming, mock/fixture patterns, and unit/integration ratio. Don't introduce new libraries or patterns.

Rules

1. Test business behavior, not implementation Ask: "If this breaks in production, will my tests catch it?" Test what the system does, not how it does it internally.

2. Pragmatic edge cases only Cover edges that are likely to break: null inputs the code doesn't guard, auth boundaries, external integrations. Skip exhaustive permutations, every null combination, unicode/float precision unless the domain demands it.

3. Don't fragment — merge similar tests If tests differ only by one input value or minor condition, merge them or use the project's parameterized pattern. Ask: "Same story or different story?" Same story → one test.

4. Assert only what the caller cares about Don't assert every field in a large object when 2 matter. Don't assert internal state or that a specific method was called. Over-asserting makes tests brittle — they break on irrelevant changes.

5. Never delete a failing test A failing test is signal — either the code is broken or the test needs fixing. Deleting it to make the suite pass is never the right call. Fix the code, or update the test if the behavior intentionally changed.

6. Match the repository tone of voice Test descriptions, error messages, mock data, and comments should feel consistent with how the rest of the codebase is written. If the repo uses "blows up if user is missing", don't write "should throw InvalidUserException when user entity is null". No comments that restate the code. Fake data should feel plausible, not "test-string-123".

7. Name tests as behavior documentation "should reject checkout when cart is empty" not "test_checkout_2". A failing test name should tell you exactly what broke.

Sizing guide

For a typical feature: 1–2 happy path tests + 2–4 meaningful failure cases. Stop when you'd be comfortable shipping — not when coverage is maxed.

Common scenarios

• "Write tests for this function" → Test its business purpose, not every branch.
• "Add coverage to this file" → Only where there's real risk of breakage.
• "We need 80% coverage" → Get there with meaningful tests; flag any padding explicitly.
• "Test this endpoint" → Success shape + auth rejection + 1–2 likely bad inputs.