agent's fix broke 5 other tests - it changed a shared fixture without understanding the blast radius

TL;DR

Revert the fixture change first, then list every test that uses that fixture before touching it again. Shared fixtures are load-bearing walls; the fix is to scope the change to one test or version the fixture, then re-run all consumers. Never edit a shared fixture on a guess about who uses it.

The exact query

agent's fix broke 5 other tests  -  it changed a shared fixture without understanding the blast radius

Steps

1. Revert the agent's fixture change immediately. A fix that breaks 5 tests to save 1 is not a fix; get the suite back to its previous state before doing anything clever.

Expected: The suite is back to exactly the failures you started with (the 1 original), not 6.

1. Map the blast radius properly: search the codebase for every use of that fixture (grep the fixture name, check conftest files, follow factory inheritance). Write down the full consumer list.

Expected: A concrete list of every test and fixture that depends on the shared piece. No guessing.

1. Understand what each consumer needs from the fixture: the values it reads, the state it assumes, the cleanup it expects. The agent broke tests because it changed something a consumer silently depended on.

Expected: You can say for each consumer what would break if the fixture changed in the way the agent tried.

1. Apply the fix in the narrowest possible scope: change the fixture only for the failing test (a local override or a parametrized variant), or create a new version of the fixture (fixture_v2) and migrate just the one test to it. Leave every other consumer untouched.

Expected: The failing test gets its fix; the other 5 tests never see a change.

1. Re-run the full consumer list plus the originally failing test. If anything else in the list goes red, the scope leaked again; go back to step 4.

Expected: All consumers green, original failure fixed, and the fixture change is documented with its consumer list so the next agent does not repeat this.

Use this when

• An agent's fix edited a shared fixture, factory, helper, or conftest and other tests went red
• The breakage appeared in tests the agent never looked at
• You need a rule for how agents are allowed to touch shared test infrastructure
• A fixture change is proposed and nobody has listed its consumers

Not for this skill when

• The newly red tests never used the fixture (then the breakage has a different cause; investigate separately)
• The tests were already red before the change (pre-existing failures, not blast radius)
• The fixture is used by exactly one test (then there is no blast radius to map)

Variant phrasings

agent changed conftest and half the suite broke

Same pattern, bigger blast radius. Revert, map consumers, scope the change.

fixing one test broke the factory for everyone

The factory is the shared fixture here. Version it or parametrize it instead of editing the shared path.

how to safely change a shared pytest fixture

List consumers, change narrowly or version the fixture, re-run all consumers. That is the whole procedure.

Why it happens

Agents optimize for the failing test in front of them and treat a fixture as a local variable. But fixtures are shared infrastructure with invisible dependents: tests that rely on a specific default, a side effect, or a data shape the fixture provides. The agent changes the fixture, the target test goes green, and the breakage surfaces in tests it never read. Nobody mapped the dependency graph, so the blast radius was a surprise.

Edge cases

• Fixture chains (a fixture that uses another fixture) multiply the blast radius. Map the transitive closure, not just direct consumers.
• Autouse fixtures affect every test in scope silently. Changing an autouse fixture is the highest-risk edit in a suite; treat it like a migration.
• Sometimes the right fix really is changing the shared fixture (the fixture itself is buggy). Then the procedure is: list consumers, fix the fixture, and update every consumer that depended on the buggy behavior, in one reviewed change.
• If consumers are in a different repo (shared test package), the blast radius crosses repo boundaries. Version the package and migrate consumers explicitly.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jBavK5JcdV-5A7r532qfqQ