unit-testing

Focus on the unit's behavioral contract rather than coverage. Identify what the unit promises, explore failure modes and boundaries, then write tests with strong assertions that would fail if a realistic regression such as a removed validation or wrong error mapping were introduced.

Use the existing-code flow: inspect the implementation, callers, and documentation to reconstruct the behavioral contract, distinguish intended from accidental behavior, document a test cause, then implement only high-value scenarios. Treat current behavior as evidence, not automatically as specification.

Use a stub for controlled return values, a mock when verifying an interaction is itself part of the contract, a fake when a lightweight working implementation gives better realism, and a spy to observe without replacing behavior. Prefer the simplest double that preserves meaningful behavior.

Yes, the framework is stack-agnostic and adapts to the project's existing test runner, mocking conventions, fixtures, and naming. It explicitly forbids introducing new testing libraries solely because they are preferred in the abstract.

A suite can have high coverage while missing failure paths, incorrect state transitions, boundary conditions, and negative behavior. Coverage is a signal, not proof; tests should be evaluated by whether realistic regressions would cause them to fail.

Define a preservation contract, create characterization tests for behavior you intend to keep, establish a green baseline, refactor in small steps, and classify every test failure before changing anything. Never weaken an expectation just to make a failing test pass.