Top Cypress Plugins for End-to-End Testing

The right Cypress plugin depends on what your end-to-end (E2E) suite is missing. Use @testing-library/cypress for role- and label-based DOM queries, cypress-axe for automated accessibility checks, cypress-real-events for native-style browser interactions, @cypress/code-coverage for coverage reporting, @cypress/grep to filter tests, or a community Cucumber preprocessor if your team needs Gherkin.

These packages are independently maintained software, not built-in Cypress features. Cypress labels some directory entries official and others community-owned; community plugins are not reviewed by Cypress. Check each package’s maintenance, declared Cypress compatibility, installation steps, and license against your project before adopting it. The directory showed Cypress 16.1.1 as the latest release checked for this guide, released September 29, 2026, so recheck compatibility when installing.

Choose by the gap in your test suite

Need	Option	What it adds	Important caveat
Queries based on roles, labels, or visible text	`@testing-library/cypress`	Testing Library `findBy` and `findAllBy` queries as Cypress commands.	Import its commands and check current package support.
Automated axe-core checks	`cypress-axe`	Accessibility checks in Cypress flows.	Community package; automated findings need human review.
Managed accessibility reports	Cypress Accessibility	Reports on unique states visited by E2E and component tests, integrated with Cypress Cloud.	A separate paid Cypress Cloud solution, not an npm plugin.
Hover, swipe, or other native-style events	`cypress-real-events`	Native system events for interactions that ordinary Cypress commands may not reproduce.	Community project; verify Cypress version range and maintenance.
Gherkin test authoring	Community Cucumber preprocessor	Lets a team author tests with feature files and step definitions.	Not officially supported by Cypress; adds workflow complexity.
Coverage reporting	`@cypress/code-coverage`	Coverage integration for E2E, unit, and full-stack workflows.	Typically requires app instrumentation and project-specific setup.
Filter specs by title or tag	`@cypress/grep`	Title and tag filtering; listed as official in the Cypress plugin directory.	Check directory and package metadata for current compatibility.

There is no evidence here for a universal “best” plugin or independently measured quality ranking. Pick one that addresses a concrete suite problem, and review what it costs in maintenance, configuration, and CI complexity.

How to evaluate a Cypress plugin

Name the testing gap. For example, decide whether tests need better user-facing selectors, accessibility feedback, native browser events, coverage, faster test selection, or Gherkin authoring.
Check ownership and upkeep. Use the Cypress plugin directory to distinguish official from community entries. For a community package, inspect its release history, issue activity, license, supported Cypress versions, and installation documentation.
Match versions before installing. Compare the package’s peer dependencies and compatibility range with the Cypress version in your lockfile. Do not assume a package that worked on an older Cypress release still works on the current one.
Try it in a small representative spec. Confirm it runs in your local browser and CI environment, behaves with your app’s framework and bundler, and gives results your team can act on.
Keep the addition focused. Add only the commands and configuration the suite needs. Document why the dependency exists and who will maintain it.

1. Testing Library: query the interface the way users encounter it

@testing-library/cypress adds queries such as findByRole, findByLabelText, and findByText to Cypress. These queries are useful when tests should locate controls through their accessible role, label, or visible text rather than depend on implementation-specific CSS selectors. Cypress’s FAQ points users to this integration and its query methods.

Install and configure

npm install --save-dev @testing-library/cypress

Import the package’s commands from the Cypress support file used by your project. In the common E2E support-file setup:

// cypress/support/e2e.js
import '@testing-library/cypress/add-commands';

Then use the queries in a spec:

// cypress/e2e/sign-in.cy.js
describe('sign-in form', () => {
  it('submits credentials', () => {
    cy.visit('/sign-in');
    cy.findByRole('textbox', { name: /email/i }).type('dev@example.com');
    cy.findByLabelText(/password/i).type('example-password');
    cy.findByRole('button', { name: /sign in/i }).click();
    cy.findByText(/welcome/i).should('be.visible');
  });
});

Use accessible names that reflect the interface. If a query does not find an element, first check the rendered role, label, or text; a selector failure can reveal a genuine accessibility or markup problem. The Testing Library integration documentation was last updated November 26, 2023, so verify current package behavior and version support before adopting its exact setup.

2. Accessibility: community axe checks or managed reports

cypress-axe is a community option for running axe-core checks in Cypress. Cypress Accessibility is a separate paid Cypress Cloud service that reports on unique states reached during E2E and component tests and integrates results with CI. Choose the package when you want to add checks to your existing test workflow; consider the hosted service when managed reporting in Cypress Cloud fits your team.

Example with cypress-axe

Follow the package’s current installation instructions and import its commands in the Cypress support file. A typical spec runs a scan after the page reaches the state being checked:

// cypress/e2e/home-accessibility.cy.js
describe('home page accessibility', () => {
  it('has no detected axe violations in the initial state', () => {
    cy.visit('/');
    cy.injectAxe();
    cy.checkA11y();
  });
});

Run checks on meaningful states, including menus or dialogs after opening them. Automated checks find only some accessibility issues. Cypress’s documentation recommends complementing automation with human judgment; keyboard use, content clarity, and assistive technology behavior still need review.

3. Native-style interactions: cypress-real-events

Use cypress-real-events when a test needs browser events such as hover or swipe that should behave like native system input. It is community-maintained, so check its current Cypress compatibility range and setup instructions before using it.

npm install --save-dev cypress-real-events

// cypress/support/e2e.js
import 'cypress-real-events/support';

// cypress/e2e/navigation.cy.js
describe('navigation menu', () => {
  it('opens on hover', () => {
    cy.visit('/');
    cy.get('[data-cy=products-menu]').realHover();
    cy.findByRole('link', { name: /integrations/i }).should('be.visible');
  });
});

Use stable selectors to locate the target, then assert the user-visible result. Native-event support does not mean Cypress is driving a physical mobile device: Cypress tests browser experiences, including responsive layouts and mobile web views, rather than native mobile apps.

4. Cucumber: use Gherkin when it helps the team

Cypress confirms that Cucumber-style authoring is possible through a community plugin, but it does not officially support that workflow. A preprocessor adds feature-file and step-definition conventions to configuration and debugging. Choose it when shared Gherkin scenarios provide real value to product, QA, and engineering; otherwise, ordinary Cypress specs keep the workflow simpler.

There is no single setup snippet that is safe across all Cypress, bundler, and Cucumber preprocessor versions. Follow the chosen preprocessor’s current installation guide, then verify that feature files compile and run in the same CI path as your existing specs. Cypress’s FAQ discusses this limitation and tradeoff.

5. Code coverage: @cypress/code-coverage

Cypress identifies @cypress/code-coverage and a coverage guide for E2E, unit, and full-stack coverage. Coverage is most useful when the application is instrumented and the report is wired into the project’s build and reporting tools; installing the plugin alone may not produce meaningful coverage.

Use the current Cypress coverage guidance for the instrumentation and application-specific setup. Confirm that the instrumentation matches your framework and bundler, and check that the report covers the code paths you intend to measure rather than treating a percentage as a quality score.

6. Filter tests: @cypress/grep

@cypress/grep is listed as an official Cypress directory option for filtering specs by title or tags. This can help teams select focused test subsets, but filtering should not hide tests from the CI jobs responsible for full-suite coverage. Check the current directory and package documentation for the version-specific installation and configuration syntax.

Pricing and product boundaries

The Cypress App is free and MIT-licensed. Cypress Cloud has billing plans, and Cypress Accessibility and UI Coverage are separate paid solutions; verify current plan terms and availability with Cypress before budgeting. The plugins named above are npm packages with their own licensing and maintenance; do not assume every package has the same license or support model.

Reliability, performance, and maintenance

Compatibility is a reliability concern. Pin dependencies in your lockfile and validate upgrades against the Cypress version used in CI.
Keep feedback actionable. Accessibility scans and coverage reports are valuable when someone reviews and follows up on the results. Automating a report does not guarantee that a defect is fixed.
Consider suite runtime. A plugin can add work to each spec or introduce preprocessing. Measure its impact in your own suite and CI; no comparative performance benchmark is established here.
Plan for ownership. Community packages can change independently of Cypress. Assign responsibility for version checks and updates, especially for test infrastructure that blocks releases.
Control scope. More plugins mean more dependencies and configuration to maintain. Add a package for a specific need and remove it if the need goes away.

Troubleshooting

Symptom	Likely cause	What to check
Testing Library query is undefined	The Cypress commands were not imported in the support file Cypress actually loads.	Check the configured support-file path and import `@testing-library/cypress/add-commands` there.
`findByRole` cannot find a visible control	The element may lack the expected role or accessible name, or the page has not reached the expected state.	Inspect the rendered accessible name and role, wait for the relevant state, and correct the markup or query.
Plugin installation reports peer dependency conflicts	The package’s declared Cypress range does not include the installed version, or related packages conflict.	Review package metadata and release notes; choose a compatible version or another approach rather than forcing an unexplained dependency resolution.
Real-event command is missing	The support import is missing, points at the wrong support file, or the installed package setup differs.	Check the package’s current setup guide, support-file configuration, and Cypress compatibility.
Accessibility scan misses an issue	Automated rules do not cover every usability or assistive technology problem, or the scan ran before a state was rendered.	Scan the relevant state and pair automated results with manual keyboard and assistive technology review.
Coverage output is empty	The app may not be instrumented, or coverage data is not being collected or merged in the build.	Follow the current Cypress coverage guide for the framework, instrumentation, and report pipeline.
Cucumber feature files fail to load	Preprocessor, bundler, or Cypress configuration may be incompatible or incomplete.	Match the preprocessor guide to your exact Cypress and bundler versions and reproduce the failure in one small feature.

Or skip the browser setup

If your task is to capture a page rather than exercise it in an E2E test, ScreenshotNeo is a website screenshot API and MCP server. Its one-call API returns a screenshot or PDF; it is not a replacement for Cypress interaction tests.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

See the ScreenshotNeo API documentation for request options. Cookie banners, newsletter popups, and chat widgets are removed before the shot; each step can be turned off. Bot checks, blank pages, and failed loads are never billed, and response headers identify the page verdict and billing status. Its MCP server gives AI agents screenshot, page-info, and PDF-capture tools. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 shots. Every feature is available on every plan.

Create a free ScreenshotNeo account for 1,000 screenshots a month with no card.

FAQ

Can I use Testing Library?

Yes. Cypress’s FAQ points to @testing-library/cypress for queries such as findByRole and findByText. Check the integration’s current version support.

Can Cypress test native mobile apps?

No. Cypress supports browser testing, including responsive layouts and mobile web views, but it does not run native mobile applications.

Are Cypress plugins reviewed by Cypress?

Community plugins are not reviewed by Cypress. Confirm their maintenance, license, setup, and compatibility before adding them.

Do accessibility plugins replace manual audits?

No. Automated checks are one input. Human review is still needed for deeper accessibility and assistive technology insights.