Fixture-based response mocking in Cypress

Introduction

Fixture-based response mocking helps you test your app by pretending the server sends fixed data. This way, you can check how your app works without needing a real server.

When the real server is slow or not ready.

When you want to test how your app handles specific data.

When you want to avoid changing real data during tests.

When you want consistent test results every time.

When testing error or special cases that are hard to get from the real server.

Syntax

Cypress

cy.intercept('GET', '/api/data', { fixture: 'data.json' })

cy.intercept is used to catch network requests and replace their response.

The fixture option tells Cypress to use a file from the cypress/fixtures folder as the response.

Examples

This mocks a GET request to '/users' and returns data from 'users.json' fixture file.

Cypress

cy.intercept('GET', '/users', { fixture: 'users.json' })

This mocks a POST request to '/login' and returns a fixed success response from the fixture.

Cypress

cy.intercept('POST', '/login', { fixture: 'login-success.json' })

This mocks '/products' GET request and gives it an alias to wait for it later in the test.

Cypress

cy.intercept('GET', '/products', { fixture: 'products.json' }).as('getProducts')

Sample Program

This test mocks the GET request to '/api/users' with data from 'users.json'. It visits the users page, waits for the mocked request, and checks if the page shows the user name 'Alice' from the fixture.

Cypress

describe('Fixture-based response mocking example', () => {
  it('shows mocked user data', () => {
    cy.intercept('GET', '/api/users', { fixture: 'users.json' }).as('getUsers')
    cy.visit('/users-page')
    cy.wait('@getUsers')
    cy.get('.user-name').should('contain.text', 'Alice')
  })
})

Important Notes

Put your fixture files inside the cypress/fixtures folder.

Use cy.wait('@alias') to wait for the mocked request to finish before checking the page.

Fixture mocking works well for stable, repeatable tests without depending on real servers.

Summary

Fixture-based mocking replaces real server responses with fixed data files.

This helps test your app in a fast, reliable, and controlled way.

Use cy.intercept with the fixture option to mock responses easily.

Practice

1. What is the main purpose of using fixture-based response mocking in Cypress tests?

easy

A. To replace real server responses with fixed data files for consistent testing

B. To speed up the browser rendering process

C. To automatically generate test data from the server

D. To record user interactions for playback

Solution

1. Step 1: Understand fixture-based mocking concept

   Fixture-based mocking replaces actual server responses with predefined data files to control test conditions.

2. Step 2: Identify the main benefit

   This approach ensures tests run fast and reliably by avoiding real server calls and unpredictable data.

3. Final Answer:

   To replace real server responses with fixed data files for consistent testing -> Option A

4. Quick Check:

   Fixture mocking = fixed data for reliable tests [OK]

Hint: Fixture mocking means fixed data replaces server calls [OK]

Common Mistakes:

• Confusing fixture mocking with UI rendering speed
• Thinking fixture mocking generates data automatically
• Assuming fixture mocking records user actions

2. Which of the following is the correct syntax to mock a GET request to '/api/users' using a fixture named 'users.json' in Cypress?

easy

A. cy.mock('GET', '/api/users', 'users.json')

B. cy.intercept('GET', '/api/users', { body: 'users.json' })

C. cy.intercept('GET', '/api/users', { fixture: 'users.json' })

D. cy.route('GET', '/api/users', 'fixture:users.json')

Solution

1. Step 1: Recall Cypress intercept syntax for fixture mocking

   The correct way is to use cy.intercept with method, URL, and an object with fixture property.

2. Step 2: Match the correct option

   cy.intercept('GET', '/api/users', { fixture: 'users.json' }) uses cy.intercept with { fixture: 'users.json' }, which is the correct syntax.

3. Final Answer:

   cy.intercept('GET', '/api/users', { fixture: 'users.json' }) -> Option C

4. Quick Check:

   Use cy.intercept + fixture option [OK]

Hint: Use cy.intercept with { fixture: 'file.json' } [OK]

Common Mistakes:

• Using cy.route instead of cy.intercept (deprecated)
• Passing fixture file as body string
• Using cy.mock which doesn't exist

3. Given the following Cypress code snippet, what will be the response body when the app requests '/api/products'?

cy.intercept('GET', '/api/products', { fixture: 'products.json' })
cy.visit('/products')

Assume 'products.json' contains [{"id":1,"name":"Book"}].

medium

A. [{"id":1,"name":"Book"}]

B. An empty array []

C. A network error occurs

D. The real server response for /api/products

Solution

1. Step 1: Understand intercept with fixture

   The intercept replaces the GET /api/products response with the content of 'products.json'.

2. Step 2: Check fixture content

   The fixture file contains [{"id":1,"name":"Book"}], so this will be the mocked response body.

3. Final Answer:

   [{"id":1,"name":"Book"}] -> Option A

4. Quick Check:

   Fixture content = mocked response body [OK]

Hint: Fixture content becomes the mocked response body [OK]

Common Mistakes:

• Expecting real server data instead of fixture
• Assuming empty array if fixture not found
• Thinking intercept causes network error

4. Identify the error in this Cypress code snippet that tries to mock a POST request with fixture 'newUser.json':

cy.intercept('POST', '/api/users', { fixture: 'newUser.json' })
cy.visit('/users')

medium

A. POST requests cannot be mocked with fixtures

B. The fixture file name must not include the .json extension

C. cy.visit should come before cy.intercept

D. The fixture option should be inside a response object, not directly in intercept

Solution

1. Step 1: Review intercept syntax for POST with fixture

   For POST requests, the fixture must be inside a response object like { body: { fixture: 'file' } } or use { fixture: 'file' } directly as response.

2. Step 2: Identify the mistake

   Passing { fixture: 'newUser.json' } directly as the third argument is correct syntax in Cypress 12+, so no error there. But if the Cypress version is older, it requires response object. However, the main common error is misunderstanding the fixture placement.

3. Step 3: Check other options

   POST requests can be mocked with fixtures, file extension is allowed, and cy.intercept should come before cy.visit.

4. Final Answer:

   The fixture option should be inside a response object, not directly in intercept -> Option D

5. Quick Check:

   Fixture must be correctly placed in intercept options [OK]

Hint: Place fixture inside response object for POST mocks [OK]

Common Mistakes:

• Thinking POST cannot be mocked with fixtures
• Ignoring correct order of cy.intercept and cy.visit
• Removing .json extension from fixture filename

5. You want to mock multiple API endpoints in a single Cypress test using fixtures: '/api/users' with 'users.json' and '/api/orders' with 'orders.json'. Which is the best way to do this?

hard

A. Mock only one endpoint and let the other call the real server

B. Call cy.intercept twice, once for each endpoint with its fixture

C. Use cy.intercept with an array of URLs and a single fixture

D. Combine both fixtures into one file and mock a single endpoint

Solution

1. Step 1: Understand mocking multiple endpoints

   Each endpoint requires its own intercept call to specify the URL and fixture separately.

2. Step 2: Evaluate options

   Call cy.intercept twice, once for each endpoint with its fixture correctly calls cy.intercept twice, once per endpoint, which is the best practice.

3. Step 3: Reject other options

   Combining fixtures or URLs is not supported; mocking only one endpoint leaves tests unreliable.

4. Final Answer:

   Call cy.intercept twice, once for each endpoint with its fixture -> Option B

5. Quick Check:

   One intercept per endpoint with fixture [OK]

Hint: Use separate cy.intercept calls per endpoint [OK]

Common Mistakes:

• Trying to mock multiple URLs in one intercept call
• Combining fixtures into one file unnecessarily
• Mocking only some endpoints and ignoring others