Does jest.retryTimes reset module state between retries, or are side-effect writes duplicated?

Answer to the Core Question

When a test is retried with jest.retryTimes(n), Jest **does not** automatically reset the module registry, the mock registry, or any global state. The same module instances are reused for every retry attempt, and mock call history is preserved across retries.

What Happens Between Retries?

• Module imports are cached exactly as they were after the first failed run.
• Mock implementations and call counts remain unchanged.
• Any side‑effect code inside the test body (file writes, DB inserts, counters, etc.) will execute again, potentially duplicating data.

How Reset/ Clear Options Interact

The global Jest configuration options resetModules, resetMocks, and clearMocks are applied only when Jest transitions between different test files or test suites. They are not invoked between retry attempts of the same test case.

Practical Verification Steps

1. File Write Test

   const fs = require('fs');
   const tmp = require('tmp-promise');
   
   jest.retryTimes(2);
   
   test('duplicate write on retry', async () => {
     const { path } = await tmp.file();
     fs.appendFileSync(path, 'attempt\n');
     const content = fs.readFileSync(path, 'utf8');
     expect(content.split('\n')).toHaveLength(2); // will fail on first run
   });
   

2. Mock Call Count Test

   jest.mock('./service', () => ({ doWork: jest.fn() }));
   
   jest.retryTimes(2);
   
   test('mock persists across retries', () => {
     const { doWork } = require('./service');
     doWork();
     expect(doWork).toHaveBeenCalledTimes(1); // will be 2 after retry
   });
   

Recommended Patterns to Avoid Duplicated Side Effects

• Move non‑idempotent setup to beforeAll and clean up in afterAll. The hooks run once per test file, so retries will not repeat them.
• If you must keep the operation inside the test body, manually reset state before each retry by calling jest.resetModules() and clearing mocks in a beforeEach hook. Note that this adds overhead and may not be sufficient if the side effect is external (e.g., a database).
• Avoid enabling retries for tests that perform writes to shared resources. Instead, design the test to be idempotent or isolate it behind a transaction that can be rolled back.

Is the Behavior Stable?

Across Jest 27 through 29, the described behavior is consistent. Future releases may introduce changes, but no current version guarantees automatic reset between retries.

What to Do If You Need Automatic Reset

Jest does not provide a built‑in hook for resetting state between retries. The only reliable approach is to refactor the test or add manual cleanup logic as described above.

Missing Diagnostic Detail

If you observe unexpected duplication even after following these patterns, check whether the side effect is performed by a third‑party module that caches state internally. In that case, you may need to mock or stub that module explicitly for each retry.