Jest · Unit tests that survive refactors

What are the most common Jest mistakes?

EasymistakesdebuggingflakinessUpdated Oct 2026
Quiz this track

Short answer

The common mistakes are unawaited async assertions, over-mocking, shared mutable state, arbitrary sleeps and blindly updated snapshots. Each one hides a bug or makes the suite flaky.

Mistakes worth checking first

  • Forgetting to await an async assertion, so the test finishes early
  • Mocking so much that the test only verifies wiring
  • Sharing a mutable object across tests without rebuilding it
  • Using a fixed sleep instead of waiting for a condition
  • Running jest -u without reading the snapshot diff
  • Spying on a method and never restoring it
  • Asserting on implementation details such as hook call counts
ts
test("loads the profile", async () => {
  await expect(loadProfile("u1")).resolves.toMatchObject({ id: "u1" });
});

test("shows a loading state first", () => {
  render(<Profile id="u1" />);
  expect(screen.getByRole("status")).toBeInTheDocument();
});
Await the settlement and wait for a real UI condition instead of sleeping.

Most of these mistakes share a root cause: the test is observing the wrong layer. If a test reaches into module state, internal hooks or exact call order, it is coupled to the implementation. If it observes user-visible behaviour at a stable boundary, many of the pitfalls disappear.

A flaky test is usually a real bug in the test or in the code's async handling. Treat intermittent failures as work to diagnose, not noise to rerun.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1How do you detect an unawaited assertion?
  2. 2What is the first thing you check when a test passes locally but fails in CI?
  3. 3Why is over-mocking a problem?
  4. 4How do you handle a flaky test in a shared pipeline?

Say it in the interview

The biggest mistakes are unawaited promises, over-mocking, leaked state, arbitrary sleeps and unreviewed snapshot updates. They all make a test either pass when it should fail or fail for reasons unrelated to the code. I check whether the test observes a stable boundary and whether it cleans up. A flaky test is a bug report, not something to retry away.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Jest mock interview and get scored feedback on depth, clarity and confidence.