API-first setup pattern in Cypress - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the test result of this Cypress API setup code?

Consider this Cypress test code that uses API-first setup to create a user before UI tests. What will be the test execution result?

Cypress

describe('User Profile Test', () => {
  before(function() {
    cy.request('POST', '/api/users', { name: 'Alice' }).then((response) => {
      expect(response.status).to.eq(201);
      cy.wrap(response.body.id).as('userId');
    });
  });

  it('loads user profile page', function() {
    cy.visit(`/users/${this.userId}`);
    cy.contains('Alice').should('be.visible');
  });
});

A Test fails: 'this.userId' is undefined causing visit URL to be incorrect.

B Test fails: cy.request is asynchronous and test runs before user creation.

C Test fails: API request returns 404 causing assertion failure.

D Test passes: user is created via API, profile page loads with name visible.

💡 Hint

Remember how Cypress aliases and 'this' context work inside tests.

The 'before' hook creates the user via API and saves the user ID as an alias. The test accesses it via 'this.userId' and visits the profile page. The API returns 201 status, so the test passes.

❓ assertion

intermediate

Which assertion correctly verifies API response in API-first setup?

You want to verify that the API response contains a user object with a non-empty 'id' field after creating a user. Which assertion is correct in Cypress?

Cypress

cy.request('POST', '/api/users', { name: 'Bob' }).then((response) => {
  // Which assertion below is correct?
});

A expect(response.body.id).to.be.undefined;

B expect(response.body.id).to.exist.and.to.be.a('string').and.to.have.length.greaterThan(0);

C expect(response.body).to.have.property('id', null);

D expect(response.status).to.equal(404);

💡 Hint

Check that the user ID exists and is a non-empty string.

Option B correctly asserts that the 'id' field exists, is a string, and is not empty. Other options check for undefined, null, or wrong status code.

🔧 Debug

advanced

Why does this API-first setup test fail intermittently?

This Cypress test sometimes fails with 'Cannot read property "id" of undefined'. What is the likely cause?

Cypress

before(function() {
  cy.request('POST', '/api/users', { name: 'Carol' }).then((response) => {
    cy.wrap(response.body.id).as('userId');
  });
});

it('loads user profile', function() {
  cy.visit(`/users/${this.userId}`);
  cy.contains('Carol').should('be.visible');
});

A The 'this.userId' is accessed before the alias is set because 'before' hook is asynchronous.

B The API endpoint '/api/users' is incorrect causing undefined response body.

C The test is missing a 'cy.wait()' causing timing issues.

D The 'cy.wrap' does not create an alias accessible via 'this'.

💡 Hint

Consider how Cypress handles asynchronous commands and test context.

The 'before' hook runs asynchronously but the test may start before the alias is set, causing 'this.userId' to be undefined intermittently.

❓ framework

advanced

Which Cypress command best supports API-first test setup?

In API-first testing, which Cypress command is best to create test data before UI tests?

A cy.intercept() to mock API responses without real data creation.

B cy.visit() to load the UI and create data manually.

C cy.request() to call backend API endpoints directly.

D cy.wait() to delay tests until data is ready.

💡 Hint

Think about how to create real data via backend before UI tests.

cy.request() sends real HTTP requests to backend APIs to create data, which is the core of API-first setup. Other commands do not create real data.

🧠 Conceptual

expert

What is the main advantage of API-first setup pattern in end-to-end testing?

Choose the best explanation for why API-first setup is preferred in modern UI testing frameworks like Cypress.

A It creates test data quickly and reliably via backend APIs, reducing flaky UI setup steps.

B It avoids the need for any UI tests by testing APIs only.

C It allows tests to run without any backend server by mocking all API calls.

D It requires less coding because UI interactions create all test data automatically.

💡 Hint

Think about speed, reliability, and test flakiness.

API-first setup creates data directly via backend APIs, making tests faster and less flaky than relying on UI steps to create data. It complements UI tests rather than replacing them.