Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.

Cypress testing is browser-based automated testing for modern web applications. You write tests in JavaScript or TypeScript and run them in a real browser, locally or in continuous integration (CI), to check user journeys, individual components, API behavior, and accessibility-related issues.

Cypress is not limited to end-to-end testing: its free, open-source Cypress App supports several kinds of checks. Cypress Cloud is a separate paid service for recording runs, analytics, replay, and orchestration.

What is Cypress testing?

Cypress testing means using Cypress to automate checks on a web application. Tests can interact with the browser, inspect application state, make HTTP requests, and verify that expected results occur. Developers commonly use it to find regressions before a change reaches users or to check critical flows during CI.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Cypress describes itself as “a quality platform for teams shipping modern web applications.” The practical distinction is that Cypress provides multiple testing layers, not just browser-driven checks of an entire application.

What is Cypress used for?

Teams use Cypress to test the parts of a web product where failures matter: whether a user can sign in, whether a component responds correctly to input, whether an endpoint returns the expected result, or whether automated accessibility checks identify a regression. The four principal modes are complementary; no single mode proves every layer works.

Test mode What it checks Useful for What it does not establish alone
End-to-end (E2E) A user flow through the browser, application, back end, and potentially third-party integrations Authentication, purchasing, persistence between screens, smoke tests, and pre-deployment system checks It does not provide the fastest or simplest feedback for every isolated behavior; setup and test-data management can be substantial.
Component An individual UI component mounted in a real browser Rendering, styling, and interactions such as clicking or typing A passing component test does not prove the complete application works.
API HTTP responses and backend behavior without driving the UI for each assertion Focused checks of endpoints and response behavior It does not establish that users can successfully complete the corresponding browser flow.
Accessibility Accessibility-related issues detected by tests and plugins, or through Cypress Accessibility in Cypress Cloud Finding standards-related regressions as part of development and delivery Automated checks do not replace assistive-technology testing or human review.

How Cypress end-to-end testing works

An E2E test opens an application URL in a browser, interacts with its interface as a user would, and asserts what happens. Cypress says its E2E tests run “the same way users interact with your app by using a real browser.” Depending on the flow, the test may cross the frontend, backend, and integrations such as third-party APIs or services.

For example, a purchasing test might visit a product page, add an item to a cart, submit checkout details, and verify the resulting confirmation. E2E coverage is valuable for important journeys and release confidence because it checks whether several layers work together.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

The trade-off is infrastructure and maintenance. Tests need an application environment and a deliberate strategy for creating, isolating, and resetting data. Third-party dependencies can also complicate repeatable runs. Start with a few critical user paths rather than attempting to automate every possible interaction as an E2E test.

How Cypress component testing differs from E2E

Component testing mounts one UI component in isolation on a blank canvas. Cypress runs that component in a real browser rather than a simulated DOM, so developers can inspect its appearance, interact with it, and use browser developer tools. Cypress documentation states: “Cypress Component Testing mounts your components directly in a real browser.” Official mounting libraries are available for React, Angular, Vue, and Svelte.

Use component tests when you want quick, focused feedback about rendering or behavior without bringing up the entire application flow. A form component, for instance, can be checked for validation feedback when a user enters invalid data. The isolation makes the result easier to localize, but a component passing its own checks cannot prove routing, backend integration, or the end-to-end workflow is sound.

Can Cypress test APIs?

Yes. Cypress can make arbitrary HTTP calls with cy.request(), which lets a test check API responses and backend behavior without driving the UI for every assertion. API checks are often faster and more focused than reproducing a complete user journey. They work well alongside E2E tests: an API test can check endpoint behavior directly, while an E2E test verifies that the UI and endpoint cooperate in a real flow.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Does Cypress support accessibility testing?

Yes. Cypress supports accessibility checks through tests and plugins, and Cypress Accessibility is offered as a product in Cypress Cloud for surfacing accessibility issues and standards failures. Treat these results as one part of an accessibility practice, not proof that an experience works for every person. Automated checks do not substitute for testing with assistive technologies and human review.

How Cypress works and why debugging is different

Cypress says its architecture runs in the same run loop as the application, while a Node process handles privileged work and communicates with the browser side. This gives tests access to browser and application objects such as window, document, DOM elements, application functions, timers, service workers, and browser developer tools.

Its documented features include automatic waiting, snapshots in the Command Log, readable errors and stack traces, spies, stubs, clocks, network traffic control, screenshots, and video recording. Command-log snapshots help a developer inspect what the application looked like at different points in a run. Cypress contrasts its approach with tools that send remote commands through Selenium or WebDriver; that is an architectural distinction, not a claim that one tool is universally better.

Is Cypress free?

The Cypress App is free and open source, and can be installed locally to write and run tests. Cypress Cloud is a separate paid service that records runs, presents results and analytics, supports replay, and provides orchestration features such as parallelization and spec prioritization. UI Coverage and Cypress Accessibility are described as premium solutions. Pricing and packaging can change, so check the current Cypress pricing information before choosing a Cloud plan.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

For basic local test authoring and execution, the App is the relevant product. Cloud becomes relevant when a team needs its recording, analysis, replay, or orchestration capabilities; it is not necessary to treat the App and Cloud as the same purchase.

What browsers does Cypress support?

The current Cypress browser reference lists Chrome-family browsers, including Edge, and Firefox for local and CI execution. Electron is deprecated as a test browser and is scheduled for removal in a future Cypress version. WebKit support is experimental. Browser support changes over time, so verify the browser matrix and release notes for the Cypress version you plan to run before setting a CI matrix or relying on a particular browser.

Browser coverage matters because a test passing in one browser does not establish that an application behaves identically in another. Choose browsers according to the browsers your users need, and make the supported Cypress status part of that decision.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

How to choose a Cypress test strategy

Choose the testing layer based on the risk you need to cover, then combine layers where their different evidence is useful.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  • Use E2E for critical journeys: cover flows such as login, checkout, or data persistence that need the frontend, backend, and integrations to work together.
  • Use component tests for isolated UI behavior: check rendering and interactions early without setting up a whole-system journey.
  • Use API tests for focused endpoint checks: validate responses and backend behavior directly instead of repeatedly navigating the UI.
  • Add accessibility checks to catch regressions: include automated checks, then complement them with assistive-technology testing and human review.

When planning coverage, compare the layer each test reaches, execution speed, environment complexity, debugging experience, browser coverage, CI orchestration needs, and ongoing maintenance. A balanced suite uses focused tests for rapid feedback and reserves broader E2E checks for flows where integration itself is the risk.

Cypress vs Selenium

Cypress and Selenium are both associated with browser automation, but their architectures differ. Cypress describes itself as running in the same run loop as the application and contrasts that with tools that send remote commands through Selenium or WebDriver. That design supports Cypress features such as application access, automatic waiting, and Command Log snapshots. The information here does not establish a universal winner: compare the browser coverage, CI needs, debugging approach, and test architecture required by your project rather than choosing from the label alone.

Need a screenshot without building browser automation?

Screenshot testing and Cypress testing solve different problems. Cypress runs assertions against application behavior; a screenshot API returns an image or PDF of a web page. If your task is to capture a clean page image rather than exercise your own application, ScreenshotNeo is the alternative to try first: it removes known consent banners and other interruptions before capture, and only clean shots are billed.

Or skip the browser setup

One GET request can return a screenshot. See the ScreenshotNeo API documentation for request options.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

ScreenshotNeo removes cookie banners, popups, and chat widgets before the shot; bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000. Sign up for free.

Common questions about Cypress testing

Is Cypress only for end-to-end testing?

No. Cypress supports end-to-end, component, API, and accessibility testing.

Do component tests run in a real browser?

Yes. Cypress mounts components in a real browser rather than a simulated DOM.

Does a passing Cypress component test prove the app works?

No. It verifies the isolated component behavior covered by that test, not the complete application flow.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.