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.