Why Fixtures are a Pain?

As great as fixtures are when we’re starting, using them long-term on complex projects exposes problems. Here are some things to keep an eye on.

Fixtures are global

There is only one set of fixtures in a default Rails application, so the temptation to add new data points to the fixture set every time we need a corner case is overwhelming. The problem is that every time we add a user to test what happens when a left-handed user sends a message to a user who has a friendly relationship and lives in Fiji (or whatever oddball scenario we need), every other test has to deal with that data point being part of the test data.

Fixtures are spread out

Fixtures live in their own directory, and each model has its own fixture file. That’s fine until we need to manage connections. A simple setup of a user commenting on a post related to a given article quickly spans four fixture files, with no easy way to trace the relationships.

Fixtures are distant

If we’re doing a complex test based on the specific fixture lineup, we’ll often wind up with the end data being based on the fixture setup in such a way that, when reading the test, it’s not clear exactly how the final value is derived. It would be best if we went back to the fixture files to understand the calculation.

Fixtures are brittle

Of course, once we add that left-handed user to the fixture set, we’re guaranteed to break any test that depends on the exact makeup of the entire user population. Tests for searching and reporting are notorious culprits here. There aren’t many more effective ways to kill the team’s enthusiasm for testing than having to fix 25 tests on the other side of the project every time we add new sample data.

Sounds grim, right? It’s not. Not only are fixtures perfectly suitable for simple projects, but the Rails community has responded to fixtures’ weaknesses by creating factory tools that can replace them in creating test data.