Why Fixture-based response mocking in Cypress? - Purpose & Use Cases

The Big Idea

What if you could test your app instantly without waiting for slow or broken servers?

The Scenario

Imagine testing a web app that shows user profiles. Every time you refresh, you have to wait for the real server to respond. Sometimes the server is slow or down, so you can't test properly.

The Problem

Manually waiting for real server responses is slow and unreliable. You might get different data each time, or errors that stop your tests. This makes testing frustrating and inconsistent.

The Solution

Fixture-based response mocking lets you use saved data files to fake server responses. Your tests get the same data every time, instantly and reliably, without depending on the real server.

Before vs After

✗ Before

cy.visit('/users')
cy.wait(5000) // waiting for real server response

✓ After

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

What It Enables

This makes your tests fast, stable, and repeatable, so you can focus on checking your app's behavior without waiting or guessing.

Real Life Example

When testing a shopping site, you can mock product lists with fixtures. This way, you always see the same products and prices, even if the real database changes or is offline.

Key Takeaways

Manual testing with real servers is slow and unreliable.

Fixture-based mocking uses saved data to fake responses.

This makes tests faster, stable, and consistent.

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