Tests

Tests

A change is done only after its tests exist and pass. Apply these rules to every new or altered frontend and backend behavior.

Steps — ship with tests

Step 1: Cover the behavior

1. For every new or altered behavior, add cases for the expected result, errors, boundaries, and missing data.
2. Aim for at least 80% coverage, prioritizing business rules, validation, authorization, error states, and route contracts.
3. Name each case by the observable business outcome; structure it Given/When/Then (or Arrange/Act/Assert) with one business action.

Done when: every touched behavior has at least one executed assertion-bearing test, and coverage for the changed surface is ≥80% without assertion-free padding.

Step 2: Run before delivery

1. Run the suite and coverage check for the changed project.
2. Fix every failure; re-run the relevant tests after each fix.
3. If no runner or coverage command exists, add one on the first change that requires tests — manual inspection does not replace execution.

Done when: the suite and coverage check have been executed after the final fix, coverage is ≥80%, and every failure is resolved.

Reference — FIRST and focus

• Fast — keep unit tests free of network, database, and slow services; reserve integration tests for cross-component contracts.
• Independent — each test builds its own state; order and siblings never matter.
• Repeatable — isolate uncontrolled externals with mocks, stubs, a frozen clock, and deterministic data.
• Self-validating — every relevant result goes through expect/assert; running code alone is not a test.
• Assert observable rules, input/output contracts, state transitions, and meaningful messages — not private implementation details that can change without changing behavior.