Organising mocks so they do not become the problem, Cypress Senior

Organising mocks so they do not become the problem

Thirty specs with thirty copies of the same fixture is a second application to maintain. Here is the structure that prevents it.

What you'll learn

Why fixture files multiply into a second application
How factories and scenario builders replace them
How one contract test keeps stubs honest

The previous lecture decided when to stub. This one is about how to organise the stubs, because mock sprawl becomes its own maintenance burden faster than most teams expect.

The shape of the problem: a contact object appears in eleven fixture files. The API adds a required field. You now have eleven files to update, and you will miss two, and those two tests will keep passing against a shape the server no longer produces.

Build fixtures from factories, not from files.

The instinct is to write JSON files. The better pattern is a function that produces the object, with overrides:

members only

Keep reading with the full course

The Foundations track and the first 5 lectures of each framework are free. This lecture is part of the paid course, which unlocks every lecture, all three frameworks, and downloads.

See the options →