Are Your Test Fixtures Lying to You?

You wrote the fixture two years ago. A user named Jane, a couple of orders, an invoice, enough to make the suite go green. It worked, so you moved on, and you have not really looked at it since. It still runs. It still passes. And somewhere in the last two years it quietly stopped being true.

A test fixture is supposed to be a fixed, repeatable baseline, the known state your test starts from. That is the promise, and "fixed" is exactly the problem. Your fixture is frozen at the moment you wrote it, and everything around it kept moving. The schema grew three columns. A field that was optional is now required. The business added a rule that no real Jane could violate anymore. Your fixture never got the memo, because nobody re-derives a fixture that still passes.

A fixture is a snapshot; production is a movie

Here is what makes fixtures lie so convincingly. They do not fail when they drift. They fail to fail. A row that could never exist in production today still satisfies your assertions, because the assertions were written against that same fossil. The test is green, and the green means nothing, because it is checking that yesterday's data still matches yesterday's expectations. Both sides rotted together and agreed.

Meanwhile production moved on. Real rows carry the new required field. Real rows hit the new rule. Real rows have shapes your two-year-old Jane never imagined. Your suite is passing against a world that no longer exists, and you find out the day a real row walks into code your fixtures swore was covered.

Why test fixtures rot

Fixtures rot for a boring, structural reason: they are maintained by hand, and hand-maintenance only touches what breaks the build. When the schema changes and a fixture stops compiling, you patch the one field that errored and leave the rest. You never ask whether the whole row still resembles a real one. Multiply that by fifty fixture files written by six people over three years and you do not have a baseline, you have sediment: layers of half-updated assumptions, each patched just enough to stay green.

You cannot hand-maintain your way out of this. The moment fixtures are frozen snapshots you edit reactively, drift is the default, not the exception.

Regenerate, don't maintain

The fix is to stop treating a fixture as a file you edit and start treating it as output you regenerate. Decide once what a good row actually looks like: the shape, the required fields, the realistic values, the rule it has to satisfy. Capture that as a description instead of a frozen instance, then generate your fixtures from the description. When reality changes, you change the description in one place and regenerate, instead of hunting through fifty files for the ones that lied.

That is the idea behind dugalaxy: describe what your data should look like once, get reproducible fixtures you can regenerate identically whenever the shape moves. It does not read your mind, and it validates structure rather than meaning, so you still own the judgment about what a good row is. What it changes is where that judgment lives: in one description you can update, instead of scattered across files that quietly go stale.

Next time your suite is green, do not trust it yet. Open your oldest fixture and ask one question: could this row actually exist in production today?

A fixture is a snapshot. Production is a movie. Green tests against a fossil are just two things agreeing about a world that is gone.