test isolation
Each test controls its own state and can run independently.
Use this when A test passes alone but fails in the full suite or in parallel.
without the term
“Each test passes when I run it alone, but when I run the whole suite, or in parallel, random ones fail. I think they're stepping on each other's data.”
with the term · How do you ask a model for test isolation?
Isolate these tests with independent sessions and records. Verify they pass alone and together in parallel.
What is test isolation?
Isolated tests do not rely on another test’s execution order, browser session, or mutable records.
Why does test isolation matter when vibe coding?
An agent may reuse an account or a fixture that competing tests modify.
How do you do test isolation?
Give each test independent state and cleanup. Run the affected tests alone, together, and in parallel.
What goes wrong with test isolation?
A fresh browser still points at database records shared by every test.
Before and after
One test adds a cart item. Another expects a fresh empty cart. Both pass with a fresh process, but the empty-cart check fails after the first test mutates the shared fixture.
Before
A fixture factory always returns the same cart. One test leaves state for the next; changing their order changes the outcome.
function before() {
const shared = { items: [] };
return () => shared;
}After
Create a new cart for each test rather than sharing the mutable object. Test independence in both orders. In an application, apply the same ownership rule to sessions, records, files, and other mutable resources.
function after() {
return () => ({ items: [] });
}Check the change
The shared-fixture example reproduces the exact alone-versus-together mismatch. Independent fixtures pass in both orders and retain separate mutable state when two owners exist at once.
Save the runnable comparison, then run node --test test-isolation.mjs with Node.js 22.12 or later.
Download the complete teaching example: the bug, prompt, runnable code, expected result, limits, and sources, linked back to this page.
Show the assertions
function addItem(makeCart) {
const cart = makeCart();
cart.items.push('book');
assert.equal(cart.items.length, 1);
}
function startsEmpty(makeCart) {
assert.deepEqual(makeCart().items, []);
}
test('checks pass alone but interfere when sharing the fixture', () => {
addItem(before());
startsEmpty(before());
const shared = before();
addItem(shared);
assert.throws(() => startsEmpty(shared), { code: 'ERR_ASSERTION' });
});
test('independent fixtures pass in both orders and overlapping owners', () => {
for (const order of [[addItem, startsEmpty], [startsEmpty, addItem]]) {
const fixture = after();
for (const check of order) check(fixture);
}
const fixture = after();
const first = fixture(), second = fixture();
first.items.push('book');
assert.deepEqual(second.items, []);
});When this is not enough
Fresh objects isolate this memory-only example. Separate objects do not isolate a shared database row, account, port, or filesystem path. Give parallel tests unique resources or a safe reset boundary, close resources, and restore mocks and clocks. These checks do not run multiple OS processes or measure suite flakiness; verify the actual suite under its real parallel settings.
The next decision
- test double: Control a dependency boundary after isolating each test owner.
- minimal reproduction: Record the smallest order and resource that trigger the interference.
Sources and verification
- Playwright: Test isolation
Independent tests should own their storage, session, cookies, and data. The cart example is an original memory-only illustration.
Sources checked . These are illustrative examples with automated checks. How we check content.
Did this help with your task?
After trying the prompt or check, tell us what happened. This optional response records only your choice and this term.