Why use fixtures in Cypress
Fixtures are static data files that simulate API responses or application states. Instead of depending on external services during tests, you load controlled data from JSON files. This makes your tests faster (no real HTTP calls), more stable (no timeouts or network errors), and completely reproducible.
Cypress looks for fixtures in cypress/fixtures/ by default. A common mistake is creating incorrect or oversimplified JSON structures that don't reflect the complexity of real responses. Another typical issue: forgetting to update fixtures when the API changes, which generates false positives in tests.
Fixtures shine in cy.intercept() for mocking endpoints, in cy.fixture() for loading data in custom commands, and in component tests where you need realistic props. Using them correctly speeds up your test suite by 60-80% compared to tests hitting real APIs.
Strategies for effective fixtures
Organize your fixtures by domain or entity: users/, products/, orders/. Inside each folder, create variants: user-admin.json, user-guest.json, user-suspended.json. This makes it easier to find the right fixture and maintain consistency in test data.
Include edge cases in your fixtures: users without avatars, out-of-stock products, error responses 400/401/500. Many teams only generate "happy path" cases and then discover bugs in error handling in production. Have fixtures for empty states (arrays [], objects without optional properties) and large payloads (lists of 100+ items to test pagination and scrolling).
Pro tip: use TypeScript to type your fixtures. Create interfaces matching your backend models and validate JSON with a pre-commit script. This prevents broken fixtures causing flaky tests. Also consider data generators like Faker.js to create dynamic fixtures when you need volume (e.g., 1000 unique users).
Advanced patterns with cy.intercept
The most powerful pattern: cy.intercept() + cy.fixture(). You intercept specific routes and return customized fixtures per test. Example: cy.intercept('GET', '/api/users/*', { fixture: 'users/admin.json' }). This lets you test complete flows without a working backend.
For loading state tests, use artificial delays: cy.intercept('/api/products', { fixture: 'products.json', delay: 2000 }). You verify that spinners appear and "loading" messages display correctly. To simulate network errors: cy.intercept('/api/checkout', { forceNetworkError: true }) or respond with statusCode 500 and an error fixture.
Keep fixtures versioned with your code. If an endpoint changes from v1 to v2, maintain both fixtures temporarily to facilitate rollback. And be careful with hardcoded data like IDs or timestamps: use placeholder values that are clearly fake (999, '2024-01-01') so it's obvious they're test data.
Common mistakes and how to avoid them
Mistake #1: Outdated fixtures. Backend adds a new field, tests pass because the old fixture doesn't include it, but UI breaks in production. Solution: script that compares fixtures against OpenAPI schema or Zod/Yup validations in CI pipeline.
Mistake #2: Too generic data. Fixtures with "Test User", "Example Product" lose value: they don't test special characters, long texts, or edge case formats. Use realistic data: names with accents, emails with +aliases, weird decimal prices (9.999), long URLs.
Mistake #3: Not testing empty fixtures. When an endpoint returns [], does your UI show the correct empty state? Many tests assume there's always data. Create fixtures like empty-users.json, no-results.json to verify these scenarios.
Finally: don't overuse fixtures for everything. If you need to test sorting logic or complex filters, sometimes it's better to generate data in the test itself with beforeEach() rather than maintaining 50 nearly identical fixtures.