First Stable Test
Write one Cypress test that visits your app home page, checks a visible heading, and avoids brittle CSS selectors by using data-cy attributes.
DevOps & Tooling / Knowledge library
Cypress
javascript end-to-end testing for web apps
Why learn Cypress?
Cypress helps teams ship web apps faster by running reliable browser tests close to real user behavior. It reduces flaky timing issues with automatic waiting/retries, gives fast local feedback, and fits naturally into CI/CD pipelines.
Where it came from
2015: Cypress company formed to rethink flaky front-end testing. 2017: Cypress was open-sourced and adoption accelerated in JS teams. Cypress introduced a built-in Test Runner UX that made debugging easier than many legacy tools. Component Testing matured over time, expanding Cypress beyond only end-to-end checks. Dashboard evolved into Cypress Cloud for team-level analytics and CI optimization.
- 2015: Cypress company formed to rethink flaky front-end testing.
- 2017: Cypress was open-sourced and adoption accelerated in JS teams.
- Cypress introduced a built-in Test Runner UX that made debugging easier than many legacy tools.
- Component Testing matured over time, expanding Cypress beyond only end-to-end checks.
- Dashboard evolved into Cypress Cloud for team-level analytics and CI optimization.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Write one Cypress test that visits your app home page, checks a visible heading, and avoids brittle CSS selectors by using data-cy attributes.
- Refactor a login flow using cy.session() so three protected-route tests reuse auth state. Measure runtime before and after.
- Given a flaky checkout test, add network stubbing for one unstable API call, set clear assertions, and explain why the new version is more deterministic.
- Implement a test for SSO login where identity provider runs on a different domain. Use cy.origin() and verify successful redirect back to the app.
- Design a Cypress CI strategy with test splitting and retries. Include when to fail fast, when to rerun, and how to read flake metrics in Cypress Cloud.
More ways to practice
Login Without Repeating Setup
Refactor a login flow using cy.session() so three protected-route tests reuse auth state. Measure runtime before and after.
CI Flake Triage
Given a flaky checkout test, add network stubbing for one unstable API call, set clear assertions, and explain why the new version is more deterministic.
Cross-Origin Auth
Implement a test for SSO login where identity provider runs on a different domain. Use cy.origin() and verify successful redirect back to the app.
Parallel Pipeline Design
Design a Cypress CI strategy with test splitting and retries. Include when to fail fast, when to rerun, and how to read flake metrics in Cypress Cloud.
Documentation and sources
- Official Docs (docs.cypress.io)
- Changelog (docs.cypress.io)
- GitHub Repository (github.com)
- CI Guide (docs.cypress.io)
Catalog research notes
- Modern projects use unified cypress.config.* with separate e2e/component sections.
- cy.session() is widely used to cache login state and speed CI runs.
- cy.origin() enables safer cross-origin flows (for SSO and third-party auth screens).
- Cypress Cloud added stronger flake analytics, run insights, and parallelization controls.
Connect the ideas
Alternatives
Explore next
Real World Example
Accessible Component Validation
E-commerce platforms requiring strict WCAG compliance for user interface components.
The business problem
Traditional selectors like CSS classes or IDs often fail when components are dynamically rendered or when accessibility roles are the primary interaction point, leading to brittle tests that break during UI refactors.
How this topic solves it
Cypress provides the cy.getByRole() query, which targets elements based on their ARIA roles and accessible names, ensuring that tests validate the application as a screen reader or assistive technology would perceive it.
- Identify the ARIA role of the target component (e.g., button, tab, link).
- Use cy.getByRole() to locate the element by its role and accessible name.
- Chain assertions to verify the element's state or visibility.
- Configure { hidden: true } if the element is intentionally excluded from the accessibility tree.
The process of locating and validating a UI component via accessibility roles.
Initiates the query
Scans DOM accessibility tree
Matches role and name
Validates state
- Test Script → invokes cy.getByRole → Cypress Engine
- Cypress Engine → finds match → Target Element
- Target Element → yields subject → Assertion
Implementation example
This code demonstrates using the accessibility-focused query to interact with UI components, ensuring the test relies on semantic structure rather than volatile CSS selectors.
// Locate a 'Billing' tab by its ARIA role and name
cy.getByRole('tab', { name: 'Billing' }).click();
// Verify visibility for elements hidden from the accessibility tree
cy.getByRole('button', { name: 'Submit', hidden: true }).should('be.visible');Expected business outcome
Tests become more resilient to CSS changes and provide higher confidence that the application is usable for all customers.
Limitations and checks
The query only matches elements with native HTML roles by default; using non-standard elements with role attributes requires the { native: false } option, which must be explicitly managed to avoid false negatives.