✍️ Writing E2E Test Scenarios

Planning Before Coding

The best E2E scenarios start on paper, not in the editor. Before you write a line, decide which journeys matter. As you learned in the concepts lesson, E2E tests are expensive, so spend them on business-critical paths: flows that make money, are used constantly, span multiple systems, or have broken before.

A lightweight scenario map keeps you honest. For each flow, jot down its goal, starting conditions, the steps, and the outcomes you'll assert:

Structuring a Scenario

Every solid scenario has the same skeleton you met earlier: setup, act, assert, teardown — often summarized as Arrange-Act-Assert. Laying tests out this way makes them readable and easy to debug.

describe('Shopping cart', () => {
  beforeEach(() => {
    // SETUP (Arrange): known starting state, seeded via the API
    cy.request('POST', '/api/testing/reset');
    cy.request('POST', '/api/testing/seed-products');
    cy.login('shopper@example.com', 'Password123');   // custom command
    cy.visit('/products');
  });

  it('adds a product to the cart', () => {
    // ACT: perform the user's actions
    cy.get('[data-cy="product-card"]').first().click();
    cy.get('[data-cy="quantity"]').select('2');
    cy.get('[data-cy="add-to-cart"]').click();

    // ASSERT: verify the observable result
    cy.get('[data-cy="cart-notification"]').should('be.visible');
    cy.get('[data-cy="cart-badge"]').should('contain', '2');
  });

  afterEach(() => {
    // TEARDOWN: clean up so the next test starts fresh
    cy.clearCookies();
    cy.clearLocalStorage();
  });
});

// cypress/support/commands.js
Cypress.Commands.add('login', (email, password) => {
  cy.request('POST', '/api/login', { email, password })
    .then((res) => {
      window.localStorage.setItem('authToken', res.body.token);
    });
});

Keeping Tests Independent

The single most important rule of E2E testing: every test must stand alone. A test should never assume another test ran first, left data behind, or logged someone in. If test B only passes because test A ran before it, you have a house of cards — reorder or run one in isolation and everything collapses.

To guarantee independence:

• Set up all needed state in beforeEach, not once in before
• Reset the database or use unique data (timestamps, random ids) per test
• Clear cookies and local storage between tests
• Never write test B expecting a record test A created

Seeding State the Smart Way

Suppose your test needs a logged-in user with three orders in their history. You could click through registration, then place three orders through the UI — but that's slow, brittle, and tests things unrelated to what you actually care about. The rule: set up state through the fastest reliable path, and reserve UI actions for the behavior under test.

Seed through the API

An API request is far faster than a UI walkthrough and doesn't depend on unrelated screens working:

beforeEach(() => {
  // Create the user and their orders directly — no clicking required
  cy.request('POST', '/api/testing/seed', {
    user: { email: `test-${Date.now()}@example.com`, name: 'Test User' },
    orders: 3
  });
});

Seed through cy.task for deeper access

When you need to reach the database or the file system directly, register a Node-side task in the config. Tasks run in Node, outside the browser, so they can do things the browser can't — like talking to MongoDB.

// cypress.config.js
const { defineConfig } = require('cypress');
const { MongoClient } = require('mongodb');

module.exports = defineConfig({
  e2e: {
    baseUrl: 'http://localhost:3000',
    setupNodeEvents(on, config) {
      on('task', {
        async seedUser(user) {
          const client = new MongoClient(config.env.MONGO_URI);
          await client.connect();
          await client.db('test').collection('users').insertOne(user);
          await client.close();
          return user.email;                 // tasks must return a value
        }
      });
    }
  }
});

// In a spec
it('shows the seeded user', () => {
  cy.task('seedUser', { email: 'ada@example.com', name: 'Ada' })
    .then((email) => {
      cy.login(email, 'Password123');
      cy.visit('/profile');
      cy.get('[data-cy="profile-name"]').should('contain', 'Ada');
    });
});

Stubbing the Network

cy.intercept lets you watch, wait on, and even replace network requests. It has two big jobs: waiting deterministically for a request to finish, and stubbing a response so you can test states that are hard to trigger for real (errors, empty results, slow loads).

Wait on a real request instead of guessing

Give a request an alias with .as(), then cy.wait('@alias') pauses precisely until it completes — no arbitrary sleeps.

it('loads products from the API', () => {
  cy.intercept('GET', '/api/products*').as('getProducts');
  cy.visit('/products');

  cy.wait('@getProducts');                    // waits for the exact request
  cy.get('[data-cy="product-card"]').should('have.length.greaterThan', 0);
});

Stub a response to force a state

Pass a response object and Cypress answers the request itself. This makes error and empty states trivial to test:

it('shows an error state when the API fails', () => {
  cy.intercept('GET', '/api/products*', {
    statusCode: 500,
    body: { error: 'Internal server error' }
  }).as('getProductsError');

  cy.visit('/products');
  cy.wait('@getProductsError');

  cy.get('[data-cy="error-message"]').should('be.visible');
  cy.get('[data-cy="retry-button"]').should('be.visible');
});

it('shows an empty state with no products', () => {
  cy.intercept('GET', '/api/products*', { statusCode: 200, body: [] }).as('empty');
  cy.visit('/products');
  cy.wait('@empty');
  cy.get('[data-cy="empty-state"]').should('contain', 'No products found');
});

Assert on what was sent

You can also inspect the request your app made — verifying the payload without hitting a real third party:

it('submits the sign-up form with the right data', () => {
  cy.intercept('POST', '/api/users').as('createUser');

  cy.visit('/signup');
  cy.get('[data-cy="username"]').type('newuser');
  cy.get('[data-cy="email"]').type('new@example.com');
  cy.get('[data-cy="submit"]').click();

  cy.wait('@createUser').its('request.body').should('include', {
    username: 'newuser',
    email: 'new@example.com'
  });
});

Writing Resilient Tests

A resilient test passes reliably and fails only when something is genuinely broken. The enemies of resilience are timing guesses and brittle selectors.

Never wait on the clock — wait on a condition

// ❌ Fragile: too short and it flakes, too long and it crawls
cy.get('[data-cy="search"]').type('shoes');
cy.wait(5000);
cy.get('[data-cy="results"]').should('be.visible');

// ✅ Resilient: wait on the actual network request, then assert
cy.intercept('GET', '/api/search*').as('search');
cy.get('[data-cy="search"]').type('shoes');
cy.wait('@search');
cy.get('[data-cy="results"]').should('be.visible');

Test critical flows, not every permutation

You don't need an E2E test for every filter combination. Cover the main happy path plus a couple of important failure paths (declined payment, invalid login), and let unit and integration tests handle the combinatorial explosion.

A Full Checkout Scenario

Here's everything coming together: a business-critical journey, seeded state, stable selectors, a network wait, and clear assertions — all in one independent, readable test.

// cypress/e2e/checkout.cy.js

describe('Checkout journey', () => {
  beforeEach(() => {
    // SETUP: fresh DB + seeded product + logged-in shopper, all via API
    cy.request('POST', '/api/testing/reset');
    cy.request('POST', '/api/testing/seed-products');
    cy.login('shopper@example.com', 'Password123');
  });

  it('completes a purchase and shows an order confirmation', () => {
    // Stub the payment provider so the test is fast and deterministic
    cy.intercept('POST', '/api/orders', {
      statusCode: 201,
      body: { id: 'order-123', status: 'confirmed', total: 39.98 }
    }).as('createOrder');

    // ACT: walk the real user path through the UI
    cy.visit('/products');
    cy.get('[data-cy="product-card"]').first().click();
    cy.get('[data-cy="quantity"]').select('2');
    cy.get('[data-cy="add-to-cart"]').click();

    cy.get('[data-cy="cart-icon"]').click();
    cy.get('[data-cy="checkout"]').click();

    cy.get('[data-cy="ship-name"]').type('Ada Lovelace');
    cy.get('[data-cy="ship-address"]').type('123 Analytical Ave');
    cy.get('[data-cy="ship-city"]').type('London');
    cy.get('[data-cy="ship-zip"]').type('EC1A');
    cy.get('[data-cy="place-order"]').click();

    // ASSERT: wait for the order request, then verify the confirmation
    cy.wait('@createOrder');
    cy.url().should('include', '/order-confirmation');
    cy.get('[data-cy="order-number"]').should('contain', 'order-123');
    cy.get('[data-cy="order-status"]').should('contain', 'confirmed');
  });

  it('shows an error when payment is declined', () => {
    cy.intercept('POST', '/api/orders', {
      statusCode: 402,
      body: { error: 'Your card was declined' }
    }).as('declined');

    cy.visit('/products');
    cy.get('[data-cy="product-card"]').first().click();
    cy.get('[data-cy="add-to-cart"]').click();
    cy.get('[data-cy="cart-icon"]').click();
    cy.get('[data-cy="checkout"]').click();
    cy.get('[data-cy="ship-name"]').type('Ada Lovelace');
    cy.get('[data-cy="ship-address"]').type('123 Analytical Ave');
    cy.get('[data-cy="ship-city"]').type('London');
    cy.get('[data-cy="ship-zip"]').type('EC1A');
    cy.get('[data-cy="place-order"]').click();

    cy.wait('@declined');
    cy.get('[data-cy="payment-error"]')
      .should('be.visible')
      .and('contain', 'declined');
  });
});

Checkout journey
  ✓ completes a purchase and shows an order confirmation (1284ms)
  ✓ shows an error when payment is declined (1102ms)

2 passing

Notice how each test seeds its own state, stubs the network, selects with data-cy, waits on a real request instead of a sleep, and asserts on exactly one clear outcome. That's a scenario you can trust in CI.

Practice & Quiz

describe('Posts', () => {
  it('creates a post', () => {
    cy.login('author@example.com', 'pw');
    cy.visit('/new');
    cy.get('[data-cy="title"]').type('My Post');
    cy.get('[data-cy="save"]').click();
  });

  it('shows the post in the list', () => {
    cy.visit('/posts');                       // assumes the post above exists!
    cy.contains('My Post').should('be.visible');
  });
});

describe('Posts', () => {
  beforeEach(() => {
    cy.request('POST', '/api/testing/reset');
    cy.login('author@example.com', 'pw');
  });

  it('creates a post', () => {
    cy.visit('/new');
    cy.get('[data-cy="title"]').type('My Post');
    cy.get('[data-cy="save"]').click();
    cy.get('[data-cy="save-confirmation"]').should('be.visible');
  });

  it('shows a seeded post in the list', () => {
    // Seed the post directly — don't rely on the other test
    cy.request('POST', '/api/posts', { title: 'Seeded Post' });
    cy.visit('/posts');
    cy.contains('Seeded Post').should('be.visible');
  });
});

cy.visit('/dashboard');
cy.wait(4000);
cy.get('[data-cy="stats"]').should('be.visible');

cy.intercept('GET', '/api/stats*').as('getStats');
cy.visit('/dashboard');
cy.wait('@getStats');                 // precise, no wasted time
cy.get('[data-cy="stats"]').should('be.visible');

Best Practices & Pitfalls

✅ Do

• Plan scenarios and organize suites by user journey
• Give every test its own state in beforeEach; use unique data
• Seed setup through cy.request / cy.task; test only the target flow through the UI
• Wait on aliased requests, never on the clock
• Stub slow or external services with cy.intercept
• Keep each it() focused on one clear outcome

❌ Don't

• Chain tests so one depends on another's leftovers
• Build state by clicking through unrelated screens
• Sprinkle cy.wait(ms) to paper over timing
• Try to cover every permutation with E2E — push combinations down the pyramid
• Let a single scenario grow into an 80-line catch-all

Summary

📚 Additional Resources

• Cypress Docs — Best Practices
• Cypress Docs — cy.intercept
• Cypress Docs — cy.task
• Playwright — Network mocking (the alternative)

🚀 What's Next?

You can now write E2E scenarios that are focused, independent, and resilient. But how fast does your app respond under load? Next up, Performance Testing Tools takes you from "does it work" to "does it stay fast," measuring response times and throughput before your users feel the slowdown.