MobX + Jest: Unresolved Resetting of Observable Stores Between Tests

Answer the Question First

To guarantee a clean observable tree between Jest tests you should:

1. Export a factory function that returns a fresh store instance (or use jest.isolateModules if you must keep a singleton export).
2. In each beforeEach create a new store and assign it to a test‑local variable.
3. Store the disposer returned by any autorun, reaction, when or observe you create in the test or shared setup, and call it in afterEach.
4. Do not rely on runInAction or transaction for cleanup – they only batch mutations, not detach observers.

Why Re‑creating a Store is Not Sufficient Alone

Reinstantiating the class creates a brand‑new observable tree, but any autorun or reaction that captured the old instance remains registered on MobX’s global reaction registry. Those observers will fire when the old store is mutated (e.g., by test setup code) and may leak memory if never disposed. Computed caches are lazily recomputed on the new instance, so they do not need manual clearing.

Parallel Workers & Module Isolation

Jest spawns each worker in a separate Node process, so global objects and module singletons are isolated per worker. However, within a single worker modules are cached across tests. If you export a store as a module‑level const you’ll see state bleed unless you either:

• Reassign the exported reference in beforeEach (works only if the export is a mutable variable).
• Wrap the test file in jest.isolateModules(() => { … }) to force a fresh module cache per test.
• Prefer a factory export so you can simply call it in every test.

Known Pitfalls

• Global autoruns created in test utilities or component mocks that aren’t disposed will accumulate across tests and workers.
• Timers or async code that capture a store reference can fire after the store has been replaced, producing stale state assertions.
• Using jest.mock to replace a store module without resetting the module cache can leave the original instance alive in other tests.
• MobX 5 uses decorators and observable.shallow; resetting patterns that work for MobX 6+ (makeAutoObservable) may not clear shallow proxies correctly.

Practical Example (MobX 6+)

import { makeAutoObservable } from 'mobx';

export function createTodoStore() {
  return class TodoStore {
    todos = [];
    constructor() { makeAutoObservable(this); }
    add(todo) { this.todos.push(todo); }
  };
}

// test file
import { createTodoStore } from './todoStore';
let store;
let disposer;

beforeEach(() => {
  store = new (createTodoStore())();
  disposer = autorun(() => console.log(store.todos.length));
});

afterEach(() => {
  disposer(); // detach autorun
});

it('adds a todo', () => {
  store.add('hello');
  expect(store.todos).toContain('hello');
});

What to Ask Next

To fine‑tune the recommendation for your codebase, could you confirm whether your store is exported as a module‑level singleton or created via a factory function?