Cypress Fixtures

What Is a Fixture?

A fixture is a static file, usually JSON, stored in cypress/fixtures/, representing a fixed, known piece of test data: a user object, a list of products, an API response shape. Fixtures make tests deterministic by decoupling them from whatever live data currently exists in a real backend.

// cypress/fixtures/user.json
{
  "id": 1,
  "name": "Jane Doe",
  "email": "jane@example.com"
}

// in a spec file
cy.fixture('user.json').then((user) => {
  cy.get('[data-cy="email"]').type(user.email);
});

cy.fixture() loads and parses the file, yielding a plain JavaScript object you can use directly in your test.

cy.fixture() Syntax

cy.fixture('user.json')
cy.fixture('user')              // .json extension is optional
cy.fixture('images/logo.png')   // works with non-JSON files too

• Fixture paths are relative to the cypress/fixtures/ folder by default.
• JSON fixtures are automatically parsed into JavaScript objects/arrays.
• Non-JSON fixtures (images, text, CSV) are also supported for other use cases.
• cy.fixture() can be used standalone or directly inside cy.intercept()'s response.

Fixtures Cheat Sheet

Common patterns for loading and using fixture data.

Using Fixtures to Stub Network Responses

The most common real-world use of fixtures is providing a canned response body for cy.intercept(), letting a test control exactly what the frontend receives without depending on a real backend being available or returning predictable data.

// cypress/fixtures/products.json
[
  { "id": 1, "name": "Wireless Mouse", "price": 25 },
  { "id": 2, "name": "Mechanical Keyboard", "price": 80 }
]

// in a spec file
cy.intercept('GET', '/api/products', { fixture: 'products.json' }).as('getProducts');
cy.visit('/shop');
cy.wait('@getProducts');
cy.get('[data-cy="product-card"]').should('have.length', 2);

This test is now fully deterministic: exactly two products, with known names and prices, every single run.

Aliasing Fixtures with .as()

Aliasing a fixture makes it reusable across multiple steps of the same test without reloading it, and keeps intent clear when a fixture's data is referenced several times.

beforeEach(() => {
  cy.fixture('user').as('userData');
});

it('pre-fills the profile form', function () {
  cy.visit('/profile');
  cy.get('[data-cy="name"]').should('have.value', this.userData.name);
});

Aliased fixtures are accessed via this.aliasName inside a function () {} test callback (not an arrow function, which does not bind this).

Common Mistakes

• Using an arrow function for a test that needs this.aliasName access to an aliased fixture, arrow functions don't bind this.
• Hardcoding fixture data directly in a spec file instead of a dedicated fixture file, making it harder to reuse and maintain.
• Forgetting fixture paths are relative to cypress/fixtures/, not the spec file's own location.
• Letting fixture files drift out of sync with the real API's actual response shape over time.

Key Takeaways

• Fixtures are static files (commonly JSON) stored in cypress/fixtures/ for deterministic test data.
• cy.fixture() loads and parses fixture data for direct use in a test.
• Fixtures pair naturally with cy.intercept() to stub network responses.
• Aliased fixtures need a function () {} callback, not an arrow function, to access this.aliasName.