🌍 Real World

Real World: Imagine testing the checkout flow of an e-commerce site: add a product to the cart, apply a coupon, pay, and see the order confirmation.

Imagine testing the checkout flow of an e-commerce site: add a product to the cart, apply a coupon, pay, and see the order confirmation. A real Cypress test suite usually breaks this flow apart with custom commands and the "App Actions" pattern — instead of logging in through the UI in every test, you set up the session via the API ahead of time, which both saves time and makes tests independent of each other.

Custom Command + Checkout Test

Micro Lab: Cypress — Writing assertions

Replace the TODO line with the critical line from the expected solution. This is not a real runtime; the goal is to reinforce writing the correct structure in a controlled way.

Step by Step: Cypress — Writing assertions

Determine what to assert: visibility / text / CSS / attribute

Verify element is visible with .should("be.visible")

Check text content with .should("contain.text", "Login Successful")

Verify attribute with .should("have.attr", "disabled") or "href"

When test fails, read Cypress error: expected X to ... but got Y

What is the Cypress assertion writing and verification order?

App Actions Pattern:

Instead of the Page Object Model, the Cypress community increasingly recommends the "App Actions" pattern: instead of clicking through the UI to set up state, you dispatch directly into the app's own store (Redux/Zustand). Example: cy.window().its('store').invoke('dispatch', { type: 'cart/addItem', payload: { id: 42 } }) — this skips 5 UI steps to add an item to the cart and sets up the test in seconds.

50-Test Suite — Cypress vs Selenium Run Time