Write down what correct behaviour means.
Start with the user journey, business rule or API expectation that motivated the change. Include the relevant negative cases and boundaries. Those approved expectations give the testing work an independent reference point. A test that repeats an implementation’s assumption can pass while the original requirement remains unmet, so keep the requirement visible during review.
Challenge the change from several directions.
Run supported existing unit tests, inspect API behaviour and exercise important browser journeys. Property testing can investigate an approved invariant across generated inputs. Mutation testing can reveal deliberate source changes that the suite fails to detect. Computer-use exploration adds a route for investigating approved interactions. Each method contributes evidence for its own declared scope.
- Compare actual observations with approved expectations.
- Inspect mutation survivors and generated counterexamples.
- Preserve failures when you revise or rerun a change.
Keep generated tests subject to review.
Supported model-assisted generation uses approved intent and constrained targets. Generated files and their provenance remain inspectable. New assumptions require review, and portable regression drafts need approval and execution before they contribute maintained coverage. An evaluation checks the relevant framework, source and runner support. No collection of generated tests can guarantee every defect is found or transfer the release decision away from your team.