Building a Cypress Automation Suite: How It Works and What It Covers.
Overview
Shipping a feature is one thing — knowing it still works three weeks later after five other features have been added is another. That's exactly what a Cypress automation suite is built for. It's not just a collection of tests; it's a safety net that runs automatically, covers your entire app from login to the last button on the last page, and tells you the moment something breaks. In this article, I'll walk you through how I structure a Cypress suite, what it covers, and why it's the first thing I set up on every project I take on.
What to Verify
The suite covers the whole application from three angles, what works (happy path), what should fail (validation), and what happens when things go wrong (error handling):
- Functional. Page load and empty state, form validation, full CRUD (create/edit/delete) with success and failure scenarios, navigation, filter and search, sorting, and pagination.
- API. Every call the UI makes is verified for status and data, including graceful handling of failures (showing an error message, not a blank screen).
- Auth and access. Logged-out users are redirected to login, valid/invalid login, session persists across refresh, and logout clears the session.
How to Verify
- Built with Cypress (JavaScript), one spec file per page/feature so tests are easy to find.
- Stable selectors: every interactive element has an id following the camelCase_pageName convention, so styling changes never break tests.
- Every spec follows the same internal structure (page load, create, edit, delete, API error handling) to stay predictable.
- Reliability is enforced: tests clean up their data in the after() hook, do not depend on each other, and run headed so every step is visible.
- New IDs are registered in app-constants.json as the source of truth; coverage reports (feature coverage, pass/fail history, spec registry) are updated on every run.
Testing Stack
