Choose a regression test that would fail before your fix

A test added beside a bug fix can pass without protecting the bug. It may call a new helper directly while the real route still uses the old path. It may assert that a function was invoked instead of checking the user-visible result. It may use a fixture that never reaches the failing condition. The useful question is whether the test would detect the original behavior before the fix.

Consider an illustrative search screen where an older response can overwrite a newer result. The fix controls request ordering. A regression should establish the response sequence and assert the final visible result, not merely check that a new cancellation helper exists. This article describes how to choose that test and verify its meaning without claiming that an unexecuted example has passed.

Write the bug as an observable contradiction

Describe what the user does, what happens, and what should happen. For search, the user enters a second query before the first completes; the second response arrives first; the first response arrives later and replaces the newer result. The correct result should correspond to the latest query.

Include the important timing or state precondition. Without it, a normal successful search test does not cover the defect. Avoid describing the bug only as a line of code that is wrong. That framing encourages the test to mirror the implementation. The behavior statement should remain valid if the fix later changes from cancellation to request identifiers or another sound mechanism. It is the contract the test needs to preserve.

Choose the smallest boundary that exposes it

Select a test level that includes the cause and observation. A helper test may be sufficient for a pure policy defect. A component test is more suitable when asynchronous state updates produce the wrong screen. An API or storage integration test may be necessary for authorization or atomic persistence behavior.

Do not choose an end-to-end browser test automatically. It adds environment and timing complexity that may not be needed. Conversely, do not mock away the boundary where the defect occurs. For the search example, the test must control response order while exercising the actual component state path. A practical artifact maps symptom, responsible boundary, test level, and assertion. This gives reviewers a reason for the test's scope instead of relying on a preferred framework.

Build a fixture that reaches the failure

Use synthetic values that make the two results distinguishable. The first query can return one named item and the second a different item. Create controllable deferred responses so the test resolves the newer request before the older one. Avoid arbitrary sleeps that hope the race occurs.

Keep unrelated setup minimal. A large fixture copied from another test can conceal the relevant condition and make failure hard to interpret. State which fixture values matter. If the bug involves time, inject a clock or use supported controlled-time behavior. If it involves roles, create the exact identities needed. The fixture should make the causal sequence obvious enough that another reviewer can explain why the old behavior produces the wrong result.

Assert the contract and negative outcome

Check that the final result belongs to the latest query and that the stale result is absent. Include loading or error state assertions if they are part of the reported defect. Do not settle for checking a mock call count when the user-facing state can still be wrong.

For backend regressions, inspect durable state when response status alone cannot prove the invariant. A duplicate-create fix should assert that only one business record exists, not merely that one request returned a conflict. A permission fix should assert that denied operations leave data unchanged and expose no private fields. Meaningful assertions connect directly to the contradiction in the bug statement. Avoid copying the same calculation from production code into expected values, which can reproduce the same mistake.

Prove failure before the fix safely

Run the regression against the pre-fix behavior in a controlled checkout or temporary experiment when practical. Confirm that it fails because the stale result appears, not because the fixture cannot render or a dependency is unavailable. Then run it with the fix and inspect the changed outcome.

Do not modify unrelated working changes or destructively reset the repository to perform this comparison. Use an isolated method appropriate to the project. If the pre-fix execution is not possible, say so and explain the reasoning instead of claiming it was verified. A passing test after the fix is useful evidence, but the before-and-after comparison establishes that it targets the regression rather than an unrelated happy path.

Keep synchronization deterministic

Wait for observable state or controlled promises, not fixed durations. A sleep that passes on one machine may fail under CI load or fail to trigger the intended race. Ensure asynchronous failures propagate to the test runner and that no assertion runs after the test has already completed.

Use the test framework's supported cleanup for timers, mocks, and rendered components. Resolve or reject outstanding work so one test cannot affect another. If the test requires a real database or provider sandbox, make that dependency explicit. See deterministic race testing for coordinating concurrent operations without depending on fortunate scheduling.

Avoid locking in the chosen mechanism

The test should survive a correct alternative implementation. If cancellation is replaced with a request-generation check, the search behavior should still pass. Assertions about private helper names or internal state layout make harmless refactoring expensive and can tempt developers to delete the regression.

There are cases where a lower-level mechanism is itself the contract, such as a database uniqueness constraint. Explain that boundary explicitly. Keep one focused regression for the original defect, then add other cases only when they protect distinct meaningful behavior. More tests are not automatically more confidence. A concise failure message naming the violated outcome makes the regression valuable months after the original discussion is forgotten.

Use AI to challenge the test

Give an assistant the bug statement, failing sequence, fix, and test. Ask whether the test could pass if the original defect returned. Have it propose a plausible incorrect implementation that would satisfy weak assertions. This counterexample exercise often reveals a call-count test or fixture that never exercises the problematic branch.

Review any generated test code against the framework's actual APIs and the repository's patterns. Ask the assistant to distinguish executed evidence from proposed verification. It can help simplify setup and improve assertions, but it should not declare the regression established because the test looks plausible. The final change report should say what failed before, what passed after, and which broader boundaries remain untested.

Sources

Playwright testing best practices provide a primary reference for user-facing behavior and test isolation.

Node's test runner documentation is relevant to asynchronous test execution and cleanup. The search regression is illustrative and is not presented as executed code.