API-first setup pattern in Cypress - Framework Patterns

Framework Mode - API-first setup pattern

Folder Structure

cypress/
├── e2e/                  # End-to-end test specs
│   ├── user.spec.js      # Example test file
│   └── product.spec.js
├── fixtures/             # Static test data (JSON, etc.)
│   └── example.json
├── support/              # Support files and commands
│   ├── apiCommands.js    # Custom commands for API calls
│   ├── e2e.js            # Global setup for tests
│   └── index.js          # Support file entry point
├── utils/                # Utility functions for API setup
│   └── apiHelpers.js     # Helpers for API requests
cypress.config.js         # Cypress configuration file
.env                     # Environment variables for sensitive data

Test Framework Layers

• API Setup Layer: Contains reusable API calls and setup commands in support/apiCommands.js and utils/apiHelpers.js. This layer handles authentication, data creation, and cleanup before tests run.
• Test Specs Layer: Located in cypress/e2e/, these files contain the actual test cases that use API setup commands to prepare test data before UI or API validations.
• Support Layer: Includes global hooks and custom commands in support/e2e.js and support/index.js to initialize the test environment and register API commands.
• Fixtures Layer: Holds static test data files used to feed tests with consistent input.
• Configuration Layer: Managed in cypress.config.js and environment files to control base URLs, environment variables, and test settings.

Configuration Patterns

• Environment Variables: Use .env files or cypress.env.json to store sensitive data like API tokens and credentials securely.
• Base URL and Environment Setup: Define baseUrl and environment-specific variables in cypress.config.js to switch easily between dev, staging, and production.
• Custom Commands Registration: Register API setup commands in support/e2e.js to keep tests clean and reusable.
• Data Cleanup: Implement teardown or cleanup API calls in afterEach or after hooks to maintain test isolation.

Test Reporting and CI/CD Integration

• Test Reports: Use Cypress built-in reporters or plugins like mochawesome to generate readable HTML and JSON reports after test runs.
• CI/CD Integration: Integrate Cypress tests in pipelines (GitHub Actions, Jenkins, GitLab CI) to run API-first setup tests automatically on code changes.
• Artifacts: Save screenshots, videos, and logs from test runs for debugging failed tests.
• Parallelization: Configure Cypress Dashboard or CI runners to run tests in parallel for faster feedback.

Framework Design Principles

1. API-first Setup: Prepare test data via API calls before UI or API tests to speed up tests and reduce flakiness.
2. Reusable Commands: Encapsulate API setup logic in custom Cypress commands for easy reuse and maintenance.
3. Clear Separation: Keep API setup code separate from test assertions to improve readability and debugging.
4. Environment Agnostic: Use configuration files and environment variables to run tests across multiple environments without code changes.
5. Cleanup After Tests: Always clean up test data to avoid side effects and keep tests independent.

Self Check

Where in this folder structure would you add a new custom command to create a user via API before running tests?

Key Result

Use API calls in Cypress custom commands to set up test data before running UI or API tests for faster and more reliable automation.

Practice

1. What is the main benefit of using the API-first setup pattern in Cypress tests?

easy

A. It prepares test data quickly by calling backend APIs before UI tests run.

B. It replaces UI tests completely with API tests.

C. It slows down tests by adding extra API calls.

D. It only works for frontend UI testing without backend interaction.

Solution

1. Step 1: Understand API-first setup purpose

   API-first setup means using backend API calls to prepare data before UI tests.

2. Step 2: Identify the benefit

   This approach makes tests faster and more reliable by avoiding UI data entry steps.

3. Final Answer:

   It prepares test data quickly by calling backend APIs before UI tests run. -> Option A

4. Quick Check:

   API-first setup = faster, reliable test data setup [OK]

Hint: API-first means setup via backend calls before UI tests [OK]

Common Mistakes:

• Thinking API-first replaces UI tests
• Assuming API calls slow down tests
• Believing API-first only works on frontend

2. Which of the following is the correct way to make an API call in Cypress for setup?

easy

A. cy.fetch('POST', '/users', {name: 'John'})

B. cy.api('POST', '/users', {name: 'John'})

C. cy.call('POST', '/users', {name: 'John'})

D. cy.request('POST', '/users', {name: 'John'})

Solution

1. Step 1: Recall Cypress API call syntax

   Cypress uses cy.request() to make HTTP requests.

2. Step 2: Match correct method and parameters

   cy.request('POST', url, body) is the correct syntax.

3. Final Answer:

   cy.request('POST', '/users', {name: 'John'}) -> Option D

4. Quick Check:

   Use cy.request() for API calls in Cypress [OK]

Hint: Use cy.request() for API calls in Cypress [OK]

Common Mistakes:

• Using cy.api() which is not a Cypress command
• Using cy.call() or cy.fetch() which don't exist in Cypress
• Mixing up method names or parameters

3. Given this Cypress test snippet using API-first setup:

cy.request('POST', '/api/users', {name: 'Alice'}).then((response) => {
  expect(response.status).to.eq(201)
  cy.visit('/users/' + response.body.id)
})

What will happen if the API returns status 400 instead of 201?

medium

A. The test will continue and visit the user page anyway.

B. The test will throw a syntax error.

C. The test will fail at the assertion checking response.status.

D. The test will ignore the response and pass.

Solution

1. Step 1: Analyze the assertion on response status

   The test expects response.status to equal 201.

2. Step 2: Understand behavior if status is 400

   If status is 400, the assertion expect(response.status).to.eq(201) fails and test stops with failure.

3. Final Answer:

   The test will fail at the assertion checking response.status. -> Option C

4. Quick Check:

   Assertion fails if response.status != 201 [OK]

Hint: Assertion fails if API response status is unexpected [OK]

Common Mistakes:

• Assuming test continues after failed assertion
• Thinking Cypress throws syntax error on bad status
• Believing test ignores failed API responses

4. You wrote this API-first setup code in Cypress:

cy.request('POST', '/api/items', {name: 'Book'})
  .then((res) => {
    expect(res.status).to.eq(200)
    cy.wrap(res.body.id).as('itemId')
  })
cy.get('@itemId').then((id) => {
  cy.visit(`/items/${id}`)
})

But the test fails with "Cannot read property 'then' of undefined". What is the likely cause?

medium

A. The cy.get('@itemId') runs before the alias is set.

B. The API returned status 500 causing failure.

C. The cy.request method is misspelled.

D. The cy.wrap command cannot create aliases.

Solution

1. Step 1: Understand Cypress command chaining and timing

   Cypress commands run asynchronously and in order, but alias usage requires the alias to be set before use.

2. Step 2: Identify timing issue with alias usage

   cy.get('@itemId') is called immediately, before the alias is set inside the then callback, causing undefined error.

3. Final Answer:

   The cy.get('@itemId') runs before the alias is set. -> Option A

4. Quick Check:

   Alias must be set before cy.get() uses it [OK]

Hint: Set alias before using cy.get('@alias') to avoid timing errors [OK]

Common Mistakes:

• Assuming API error causes this specific error
• Thinking cy.request is misspelled
• Believing cy.wrap cannot create aliases

5. You want to use API-first setup to create multiple users before a UI test. Which approach correctly ensures all users are created before visiting the page?

const users = [
  {name: 'Anna'},
  {name: 'Ben'},
  {name: 'Cara'}
]

// Which code snippet is correct?

hard

A. users.forEach(user => {
cy.request('POST', '/api/users', user)
cy.visit('/users')
})

B. cy.wrap(users).each(user => {
cy.request('POST', '/api/users', user)
}).then(() => {
cy.visit('/users')
})

C. for (const user of users) {
cy.request('POST', '/api/users', user)
cy.visit('/users')
}

D. cy.wrap(users).each(user => {
cy.request('POST', '/api/users', user)
})
cy.visit('/users')

Solution

1. Step 1: Understand Cypress command queue and async behavior

   Cypress commands like cy.request are asynchronous and queued. To wait for all requests, use cy.wrap().each() with a .then() callback.

2. Step 2: Analyze each option

   The native forEach and for-of options place cy.visit() inside the loop, causing visits after each request instead of after all. The cy.wrap(users).each(...) cy.visit() executes visit before requests due to queuing. Only cy.wrap(users).each(...).then(() => cy.visit()) waits for all requests before visiting.

3. Final Answer:

   cy.wrap(users).each(user => { cy.request('POST', '/api/users', user) }).then(() => { cy.visit('/users') }) -> Option B

4. Quick Check:

   Use cy.wrap().each() with then() to wait before next step [OK]

Hint: Chain .then() after cy.wrap().each() to wait for all API calls [OK]

Common Mistakes:

• Placing cy.visit() inside the forEach or for-of loop
• Using cy.wrap().each() without .then() afterward
• Not chaining .then() to wait for all iterations