What Fixtures Are For
Fixtures are static data files, usually JSON, stored in the cypress/fixtures directory, that provide known, reusable data sets for your tests instead of relying on data pulled from a live database. They're most commonly used as the body for a stubbed cy.intercept() response, but they can also supply input data for form-filling tests, expected values for assertions, or seed data sent to a backend via cy.request(). Keeping this data in dedicated files instead of hardcoding it inline keeps tests readable and lets multiple tests share the same known dataset.
Cricket analogy: A fixture file is like a standardized practice pitch report kept on file so every training session starts from the same known conditions, rather than each coach guessing pitch behavior fresh every time.
Loading Fixtures
The primary way to use a fixture is passing { fixture: 'filename.json' } directly as the response argument to cy.intercept(), which tells Cypress to read the file and use its contents as the stub body automatically. Alternatively, cy.fixture('filename.json') loads the data as a Cypress chainable, which you can .then() into a variable or alias with .as() for use later in the test, such as filling a form with values pulled from the fixture rather than hardcoded strings scattered through your test file.
Cricket analogy: Using { fixture: 'file.json' } directly in an intercept is like a broadcaster pulling a pre-recorded pitch report straight into the live feed automatically, while cy.fixture().then() is like a commentator manually reading select stats aloud from that same report.
// cypress/fixtures/user.json
// { "name": "Priya Sharma", "email": "priya@example.com", "plan": "pro" }
// Direct usage as a stub body
cy.intercept('GET', '/api/profile', { fixture: 'user.json' }).as('getProfile');
// Loading into a variable for use in the test itself
cy.fixture('user.json').then((user) => {
cy.get('[data-testid="name-input"]').type(user.name);
cy.get('[data-testid="email-input"]').type(user.email);
});
// Aliasing for reuse across multiple steps
cy.fixture('user.json').as('userData');
cy.get('@userData').then((user) => {
expect(user.plan).to.eq('pro');
});Organizing and Combining Fixtures
Fixtures can be nested in subdirectories, such as cypress/fixtures/users/admin.json, and referenced with that relative path, which helps keep large test suites organized by feature or entity type. You can also merge or override fixture data at runtime using Cypress.\_.extend or plain JavaScript object spread inside a .then() callback, letting a single base fixture serve multiple test scenarios by tweaking just the fields that differ, such as changing a status field from 'active' to 'suspended' for one specific test.
Cricket analogy: Organizing fixtures into folders by feature is like a franchise keeping separate scouting folders for batters, bowlers, and fielders instead of one giant unsorted file of every player.
Combine a base fixture with an override using object spread inside a .then() callback: cy.fixture('user.json').then((user) => { const suspended = { ...user, status: 'suspended' }; cy.intercept('GET', '/api/profile', suspended).as('getProfile'); }). This avoids maintaining near-duplicate fixture files for every minor variation.
Fixture files are read relative to cypress/fixtures by default, and a typo in the filename or an incorrect nested path will cause Cypress to throw a clear 'fixture not found' error at run time rather than silently returning undefined, so check the exact folder structure if a stub isn't returning expected data.
- Fixtures are static JSON (or other format) files stored under cypress/fixtures for reusable test data.
- { fixture: 'file.json' } loads a fixture directly as a stub response body inside cy.intercept().
- cy.fixture('file.json') loads data as a chainable you can .then() into variables or .as() into an alias.
- Fixtures can be organized into subdirectories and referenced by relative path for larger suites.
- Object spread inside .then() lets you override specific fields of a base fixture for one-off scenarios.
- A missing or misspelled fixture path throws a clear error at test run time rather than failing silently.
Practice what you learned
1. Where are Cypress fixture files stored by default?
2. What is the shorthand way to use a fixture as a stubbed intercept response?
3. How can you access fixture data outside of a stub, for example to fill a form?
4. What happens when cy.fixture() is given a path to a file that does not exist?
5. What is a good way to create a variant of an existing fixture for one specific test?
Was this page helpful?
You May Also Like
Stubbing and Mocking API Responses
Learn how to replace real backend responses with controlled, static or dynamic data using cy.intercept() to test UI states reliably.
Intercepting Network Requests with cy.intercept()
Learn how cy.intercept() lets Cypress observe, wait on, and control the XHR and fetch traffic your application sends during a test run.
Testing API Endpoints Directly with cy.request()
Learn how cy.request() lets Cypress make direct HTTP calls outside the browser to set up state, verify APIs, and speed up tests.