Fixture-based response mocking in Cypress - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the test result when mocking a GET request with fixture data?

Consider this Cypress test code that mocks a GET request to '/api/user' using a fixture named 'user.json'. What will be the output of the assertion?

Cypress

cy.intercept('GET', '/api/user', { fixture: 'user.json' }).as('getUser');
cy.visit('/profile');
cy.wait('@getUser').its('response.body').should('have.property', 'name', 'Alice');

A Test fails with a network error due to missing server

B Test fails because the fixture file is not loaded automatically

C Test passes because the fixture contains {"name": "Alice"}

D Test passes but the response body is empty

💡 Hint

Fixtures provide static data to mock API responses in Cypress.

The fixture 'user.json' contains the user data with the name 'Alice'. Cypress intercepts the GET request and returns this fixture data, so the assertion passes.

❓ assertion

intermediate

Which assertion correctly verifies the mocked response status code?

You have mocked a POST request with a fixture in Cypress. Which assertion correctly checks that the response status code is 201?

Cypress

cy.intercept('POST', '/api/create', { fixture: 'createResponse.json' }).as('createItem');
cy.visit('/create');
cy.wait('@createItem').then((interception) => {
  // Assertion here
});

A expect(interception.response.statusCode).to.equal(201);

B expect(interception.status).to.equal(201);

C expect(interception.response.status).to.equal(201);

D expect(interception.responseCode).to.equal(201);

💡 Hint

Check the Cypress interception object properties for response status code.

The correct property for the response status code in Cypress interception is 'response.statusCode'.

🔧 Debug

advanced

Why does the fixture-based mock not work as expected?

This Cypress test tries to mock a GET request with a fixture but the test fails because the real server response is received instead. What is the likely cause?

Cypress

cy.intercept('GET', '/api/data', { fixture: 'data.json' });
cy.visit('/dashboard');
cy.get('.data-item').should('have.length', 5);

A The intercept URL pattern does not match the actual request URL.

B The intercept is missing an alias and wait, so it does not block the real request.

C The cy.visit() call happens before the intercept is set up.

D The fixture file 'data.json' is empty, so the mock returns no data.

💡 Hint

Check if the URL pattern in intercept matches the actual request URL exactly.

If the intercept URL pattern does not match the actual request URL, Cypress will not mock the response and the real server response will be used.

❓ framework

advanced

How to dynamically modify fixture data before mocking response?

You want to use fixture data but change the 'id' field dynamically before returning it in the mock response. Which Cypress code snippet achieves this?

A

cy.fixture('item.json').then(data => {
  data.id = 123;
  cy.intercept('GET', '/api/item', data);
});

B

cy.intercept('GET', '/api/item', (req) => {
  cy.fixture('item.json').then(data => {
    data.id = 123;
    req.reply(data);
  });
});

C

cy.intercept('GET', '/api/item', (req) => {
  req.reply({ fixture: 'item.json', id: 123 });
});

D cy.intercept('GET', '/api/item', { fixture: 'item.json', id: 123 });

💡 Hint

Use cy.fixture() inside intercept callback to modify data before reply.

Option B loads the fixture asynchronously, modifies the 'id', then replies with the modified data, which is the correct way.

🧠 Conceptual

expert

What is the main advantage of using fixture-based response mocking in Cypress tests?

Choose the best explanation for why fixture-based response mocking is used in Cypress testing.

A It enables Cypress to record real server responses for later playback without modification.

B It automatically generates test data based on the application state during runtime.

C It replaces the need for writing assertions by validating responses automatically.

D It allows tests to run faster and more reliably by avoiding real network calls and using predefined static data.

💡 Hint

Think about test speed and reliability when avoiding real servers.

Fixture-based mocking uses static data to avoid network delays and variability, making tests faster and more stable.

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