Using fixtures in tests in Cypress - Deep Dive

Overview - Using fixtures in tests

What is it?

Using fixtures in tests means loading fixed data from files to use during test runs. This data can be JSON, images, or other files that tests need to work with. Fixtures help tests stay clean and consistent by separating test data from test code. They make it easy to reuse the same data in many tests without repeating it.

Why it matters

Without fixtures, test data would be mixed inside test code, making tests messy and hard to update. If data changes, you would have to change many tests. Fixtures solve this by keeping data in one place, making tests easier to maintain and more reliable. This saves time and reduces errors when testing web apps.

Where it fits

Before learning fixtures, you should know basic Cypress test writing and how to select elements on a page. After fixtures, you can learn about advanced data-driven testing and mocking network requests using fixtures.

Mental Model

Core Idea

Fixtures are like a test's pantry where all the fixed ingredients (data) are stored separately and brought in when needed.

Think of it like...

Imagine cooking a recipe where you keep all your spices and ingredients in labeled jars on a shelf. Instead of mixing spices directly into the dish every time, you grab the right jar from the shelf. Fixtures are those jars holding test data, ready to be used whenever a test needs them.

┌───────────────┐
│ Test Script   │
│               │
│  ┌─────────┐  │
│  │ Fixture │◄─┤
│  │ Data    │  │
│  └─────────┘  │
└───────────────┘

Test script loads fixture data from separate file to use in test steps.

Build-Up - 6 Steps

1

Foundation

What are fixtures in Cypress

Concept: Introduce the idea of fixtures as external files holding test data.

Fixtures are files stored in the 'cypress/fixtures' folder. They usually contain JSON data but can be other formats. Tests load this data to use as input or expected values. This keeps test code clean and separates data from logic.

Result

You understand that fixtures are external data files used in Cypress tests.

Knowing that test data can live outside test code helps keep tests organized and easier to update.

2

Foundation

How to load fixture data in tests

Concept: Learn the syntax to load fixture data inside a Cypress test.

Use cy.fixture('filename.json').then((data) => { /* use data here */ }) to load fixture data. The filename is relative to the fixtures folder. Inside the callback, you can use the data object in your test steps.

Result

You can load and access fixture data inside your test code.

Understanding the asynchronous nature of loading fixtures prepares you for using the data correctly in tests.

3

Intermediate

Using fixtures for test inputs and assertions

🤔Before reading on: Do you think fixture data can only be used as input, or can it also be used to check results? Commit to your answer.

Concept: Fixtures can provide both input data and expected results for assertions.

You can use fixture data to fill form fields or send API requests. Later, you can compare the app's output with fixture data to verify correctness. This avoids hardcoding values in tests and makes them more flexible.

Result

Tests become more maintainable by reusing fixture data for inputs and checks.

Knowing that fixtures serve dual roles helps write more robust and DRY (Don't Repeat Yourself) tests.

4

Intermediate

Sharing fixture data across multiple tests

🤔Before reading on: Do you think each test must load fixture data separately, or can it be shared? Commit to your answer.

Concept: Fixture data can be loaded once and shared across tests using hooks or aliases.

Use before() or beforeEach() hooks to load fixture data once and save it as an alias with cy.fixture('file').as('data'). Then access it in tests with this.data. This reduces repeated loading and keeps tests DRY.

Result

Fixture data is efficiently reused across tests without duplication.

Understanding sharing fixture data improves test speed and reduces boilerplate.

5

Advanced

Using fixtures to mock API responses

🤔Before reading on: Can fixtures be used to fake server responses in tests? Commit to your answer.

Concept: Fixtures can simulate backend API responses to test frontend behavior without real servers.

Use cy.intercept() with fixture data to stub network requests. For example, cy.intercept('GET', '/api/users', { fixture: 'users.json' }) makes the app receive fixed data from the fixture instead of the real server. This isolates frontend tests and makes them reliable.

Result

Tests run faster and more reliably by controlling backend data with fixtures.

Knowing how to mock APIs with fixtures enables testing edge cases and error states easily.

6

Expert

Managing large fixture data and performance

🤔Before reading on: Do you think loading very large fixture files always improves tests? Commit to your answer.

Concept: Large fixture files can slow tests; managing size and structure is key for performance.

Split large fixture files into smaller, focused files to load only needed data. Use JSON schemas to validate fixture structure. Avoid loading huge files in every test to keep tests fast. Consider generating fixture data dynamically if static files become unwieldy.

Result

Tests remain fast and maintainable even with complex data needs.

Understanding fixture size impact prevents slow tests and maintenance headaches in large projects.

Under the Hood

When cy.fixture() is called, Cypress reads the fixture file asynchronously from the disk before the test runs. It parses the JSON or file content and passes it to the test via a promise-like interface. Cypress manages this asynchronously to avoid blocking test execution. When used with cy.intercept(), Cypress replaces real network responses with fixture data by intercepting HTTP calls at the browser level.

Why designed this way?

Separating test data into fixtures was designed to keep tests clean and maintainable. Asynchronous loading matches Cypress's command queue model, ensuring tests wait for data before proceeding. Intercepting network calls with fixtures allows frontend tests to run without backend dependencies, improving speed and reliability. This design balances simplicity, flexibility, and performance.

┌───────────────┐       ┌───────────────┐
│ Test Script   │       │ Fixture File  │
│               │       │ (JSON, etc.)  │
│  cy.fixture() │──────▶│ Read from Disk│
│               │       └───────────────┘
│  .then(data)  │
│  Use data     │
└───────────────┘

For intercept:

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ App Requests  │──────▶│ cy.intercept()│──────▶│ Fixture Data   │
│ (HTTP call)   │       │ returns data  │       │ replaces reply │
└───────────────┘       └───────────────┘       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think fixture data is loaded synchronously and immediately available? Commit to yes or no.

Common Belief: Fixture data is loaded instantly and can be used like normal variables.

Reality: Fixture loading is asynchronous; you must use .then() or aliases to access data after loading.

Why it matters: Ignoring async loading causes tests to fail or use undefined data, leading to flaky tests.

Quick: Can fixtures only be JSON files? Commit to yes or no.

Common Belief: Fixtures must be JSON files only.

Reality: Fixtures can be any file type supported by Cypress, including images, text, or custom formats.

Why it matters: Limiting fixtures to JSON restricts test scenarios, missing opportunities to test file uploads or other features.

Quick: Does using fixtures guarantee tests are independent of backend changes? Commit to yes or no.

Common Belief: Using fixtures completely isolates tests from backend changes.

Reality: Fixtures help isolate tests but only if network calls are stubbed; otherwise, tests still depend on backend state.

Why it matters: Assuming full isolation without stubbing leads to flaky tests when backend data changes unexpectedly.

Quick: Do you think loading large fixture files always improves test reliability? Commit to yes or no.

Common Belief: Loading large fixture files is always better for test coverage.

Reality: Large fixtures can slow tests and make maintenance harder; smaller focused fixtures are better.

Why it matters: Ignoring fixture size can cause slow test suites and harder debugging.

Expert Zone

1

Fixtures loaded with aliases (cy.fixture().as()) are accessible via 'this' context only in function() style tests, not arrow functions.

2

When stubbing APIs with fixtures, ensure the fixture data matches the API contract exactly to avoid false positives.

3

Dynamic fixture generation or modification during tests can be done but requires careful handling to avoid test flakiness.

When NOT to use

Fixtures are not ideal when test data must be highly dynamic or generated on the fly. In such cases, use programmatic data creation or API calls to set up test state. Also, avoid fixtures for very large datasets that slow tests; consider mocking or database seeding instead.

Production Patterns

In real projects, fixtures are used to mock backend APIs during frontend testing, share common user profiles or settings across tests, and simulate error responses. Teams often organize fixtures by feature or data type and combine them with cy.intercept() to create stable, fast, and isolated test suites.

Connections

Mocking and Stubbing

Fixtures are often used together with mocking to simulate external systems.

Understanding fixtures helps grasp how mocking replaces real data with controlled test data, improving test isolation.

Data-Driven Testing

Fixtures provide the fixed data sets that data-driven tests iterate over.

Knowing fixtures enables writing tests that run the same steps with many inputs, increasing coverage efficiently.

Configuration Management (DevOps)

Fixtures resemble configuration files that separate data from code in deployment pipelines.

Recognizing this pattern shows how separating data from logic is a common best practice across software disciplines.

Common Pitfalls

#1 Using arrow functions with fixture aliases and expecting 'this' to work.

Wrong approach:

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

it('uses fixture', () => {
cy.get('input').type(this.userData.name)
})

Correct approach:

beforeEach(function() {
cy.fixture('user').as('userData')
})

it('uses fixture', function() {
cy.get('input').type(this.userData.name)
})

Root cause:

'this' is undefined in arrow functions, so fixture aliases are not accessible.

#2 Loading fixture data without waiting for the promise to resolve.

Wrong approach:

const data = cy.fixture('data.json')
cy.get('input').type(data.name)

Correct approach:

cy.fixture('data.json').then((data) => {
cy.get('input').type(data.name)
})

Root cause:

cy.fixture() returns a chainable, not the data directly; must use .then() to access.

#3 Hardcoding test data inside tests instead of using fixtures.

Wrong approach:

it('fills form', () => {
cy.get('input').type('John Doe')
cy.get('email').type('[e-mail]')
})

Correct approach:

cy.fixture('user.json').then((user) => {
cy.get('input').type(user.name)
cy.get('email').type(user.email)
})

Root cause:

Mixing data and test logic reduces maintainability and reusability.

Key Takeaways

Fixtures keep test data separate from test code, making tests cleaner and easier to maintain.

Loading fixture data is asynchronous; always use .then() or aliases to access it safely.

Fixtures can be used both for input data and expected results, improving test flexibility.

Combining fixtures with network stubbing allows reliable frontend tests without backend dependencies.

Managing fixture size and structure is important to keep tests fast and maintainable.