Test fixture
The known-good data or state a test starts from, defined once and reused so every test doesn't rebuild the world.
See it
What it is
A fixture is the known-good starting state a test runs against, defined once and reused. The word covers two things people use it for: the data itself (a 'users.json' sample payload, a prebuilt Order object) and the mechanism that supplies it (pytest's '@pytest.fixture', Playwright's 'test.extend', a 'beforeEach' that seeds a database, Rails YAML fixtures). Both answer the same question: what exists before the test acts?
Reach for one the second test needs the same setup as the first. The modern preference is a factory over a static blob: a 'makeUser(overrides)' helper that fills every required field with sensible defaults and lets each test override only what it cares about. That keeps the interesting detail visible in the test instead of buried in a shared file three directories away.
Two ways fixtures rot. A shared mutable fixture leaks: test A pushes onto an array, test B fails, and only when they run in that order, so rebuild per test rather than importing one shared object. And the kitchen-sink fixture with forty fields makes tests unreadable, because nobody can tell which field the assertion actually depends on.
Ask AI for it
Replace the copy-pasted setup in these tests with fixtures. Write a typed factory per entity (makeUser, makeOrder) that fills all required fields with valid defaults, accepts a partial overrides object, and returns a fresh instance on every call so nothing is shared between tests. Move any database seeding into a beforeEach that creates records and an afterEach that rolls back or truncates, keep the field each test actually asserts on visible inline in the test body, and update the existing tests to use the factories.