Bird
Raised Fist0
Cypresstesting~15 mins

Fixture-based response mocking in Cypress - Build an Automation Script

Choose your learning style10 modes available
Mock API response using fixture in Cypress
Preconditions (3)
Step 1: Open the application page that triggers the GET request to '/api/user'
Step 2: Intercept the GET request to '/api/user' and respond with the fixture 'user.json'
Step 3: Verify that the UI displays the user data from the fixture
✅ Expected Result: The UI shows user information exactly as defined in the 'user.json' fixture file, confirming the API response was mocked successfully.
Automation Requirements - Cypress
Assertions Needed:
Verify the GET request to '/api/user' is intercepted and responded with fixture data
Verify the UI displays user name and email from the fixture
Best Practices:
Use cy.intercept() with fixture option to mock API response
Use alias for intercepted request and wait for it
Use data from fixture for assertions
Keep fixture files organized in cypress/fixtures folder
Automated Solution
Cypress
describe('Fixture-based response mocking test', () => {
  beforeEach(() => {
    cy.intercept('GET', '/api/user', { fixture: 'user.json' }).as('getUser');
    cy.visit('/user-profile');
  });

  it('should display user data from fixture', () => {
    cy.wait('@getUser');
    cy.fixture('user.json').then((user) => {
      cy.get('[data-cy=user-name]').should('contain.text', user.name);
      cy.get('[data-cy=user-email]').should('contain.text', user.email);
    });
  });
});

This test uses cy.intercept() to mock the GET request to /api/user with the fixture user.json. The as('getUser') creates an alias to wait for the request to complete. The test visits the user profile page, waits for the mocked API call, then loads the fixture data again to assert that the UI elements display the expected user name and email. Using data-cy attributes for selectors follows best practices for stable tests.

Common Mistakes - 3 Pitfalls
Not using alias and wait for intercepted request
Hardcoding selectors like classes or ids that may change
{'mistake': 'Not placing fixture files in the correct folder', 'why_bad': "Cypress won't find the fixture file if it's not in the <code>cypress/fixtures</code> folder, causing test errors.", 'correct_approach': 'Always keep fixture JSON files inside the <code>cypress/fixtures</code> directory.'}
Bonus Challenge

Now add data-driven testing with 3 different user fixtures to verify the UI displays each user's data correctly

Show Hint

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard