ScreenshotNeo

BlogGuides

Best Cypress Plugins for Test Automation

Choose Cypress plugins by the testing gap you need to fill: accessibility, coverage, visual regression, component testing, or reporting.

By the ScreenshotNeo team4 October 20267 min read

The best Cypress plugin depends on the gap in your test suite. For accessibility scans, consider the community cypress-axe package; for coverage, use the official @cypress/code-coverage package; for visual regression, compare the hosted integrations Cypress documents; and for component testing, use the React or Vue package that matches your framework. Check each package’s ownership, maintenance, Cypress compatibility, and setup instructions before installing it.

There is no universal winner. Cypress’s plugin directory includes official, community, and deprecated entries across accessibility, coverage, visual testing, reporters, bundlers, network helpers, and CI integrations. Community packages are maintained by their respective communities, so evaluate them as third-party dependencies. See the Cypress plugin directory and recheck its current metadata before choosing.

1. What counts as a Cypress plugin?

“Plugin” is used broadly. It can mean a package that adds commands to test code, connects Cypress to a coverage or visual-testing service, configures a preprocessor, or adds a reporter. The correct choice follows from the job you need done, not a popularity ranking.

Registration depends on where the code runs:

  • Node-side setup: preprocessors, browser launch handlers, and filesystem tasks belong in setupNodeEvents.
  • Browser-side test behavior: custom commands and assertions belong in the Cypress support file.

Installing a package alone is not enough; follow its current README and Cypress’s plugin setup guide.

2. Best plugins by testing job

Need Documented option When to choose it Check before adopting
Accessibility scans Community cypress-axe You want to run Axe Core checks within a test against a page or component. Review the package’s coverage, Cypress compatibility, and limitations. Automated scans do not prove full accessibility conformance.
Code coverage Official @cypress/code-coverage You need coverage data collected during Cypress tests. Confirm the version and Cypress support range for your project; directory metadata changes over time.
Component testing Official React or Vue packages bundled with Cypress You test components in the framework your application uses. Check framework and Cypress version requirements and the current setup guide.
Visual regression Percy, Sauce Labs Visual, Happo, LambdaTest SmartUI, SmartBear VisualTest, or Wopee.io You need screenshot snapshots and a baseline review workflow. Compare rendering environment, browser and viewport coverage, capture granularity, approvals, account needs, compatibility, and current cost.
Reporting allure-cypress, cypress-terminal-report, and other directory entries You need a particular report format or CI artifact. Check output format, screenshots and steps support, Cypress range, and maintenance.
Network helpers or CI integration Options in the Cypress directory Your suite has a specific request-helper, orchestration, or CI workflow need. Validate the package’s current source, support range, and maintenance status.

The directory is a catalog, not a controlled quality benchmark. A recent update date is useful evidence but does not establish security or quality. Cypress marks entries official, community, or deprecated; its guide says to verify compatibility.

Accessibility: use automated checks as one layer

Cypress documents cypress-axe as a community integration that adds commands for injecting Axe Core and running checks. Choose the rules and page states deliberately, then add manual testing or Cypress assertions for relevant gaps. Cypress Accessibility is a paid Cypress Cloud solution, distinct from an in-test library. Cypress cautions users to understand the selected tool’s coverage and limitations in its accessibility testing guide.

Visual regression: compare workflow, not just snapshots

Cypress documents several visual-testing integrations rather than naming one universal winner. Compare where rendering happens (locally, in a hosted service, or across cloud browsers), whether you need full-page, element, or component captures, how baselines are approved, what CI and account setup is needed, and which Cypress and Node versions are supported. Verify vendor pricing directly before making a cost comparison; the cited research does not establish current prices.

As one specific example, BrowserStack’s current Percy integration guide states prerequisites of Percy Cypress SDK 3.0.0 or later, Cypress 13.10, and Node.js 20.9. Treat these as requirements in that guide for that integration, not as universal requirements for visual testing. See the Percy Cypress integration guide.

3. Install and register a plugin

  1. Identify the test gap and pick a package that addresses it.
  2. Check the Cypress directory and the package’s current README for ownership, supported versions, prerequisites, and update history.
  3. Install the package using the command documented by its current maintainer. Cypress describes plugins as versioned npm packages and demonstrates installing them as development dependencies.
  4. Register Node-side behavior in setupNodeEvents and browser-side commands in the support file, as required by the package.
  5. Run a focused test locally, then confirm the same configuration works in the project’s CI environment.

Do not copy setup snippets from an old article without checking the package’s current documentation. Package APIs and compatibility ranges can change.

Where configuration belongs

Use setupNodeEvents for work that needs the Node process, such as a filesystem task or a browser launch handler. Use the support file for commands and assertions available to browser tests. Some packages need both locations; follow their README rather than assuming one registration point covers everything.

4. A selection checklist

  • Does this package close a specific test gap?
  • Is it official, community-owned, or deprecated?
  • Does its documented Cypress version range include your installed version?
  • Are its Node and framework prerequisites compatible with your project and CI?
  • Does its setup put Node-side and browser-side code in the right places?
  • For hosted tools, have you checked account requirements, baseline workflow, limits, and current pricing?
  • For accessibility, have you identified what the automated rules miss and planned other checks?
  • Can you explain how the team will update, review, and remove the dependency?

5. Troubleshooting common setup problems

Symptom Likely cause What to check
Commands added by a package are undefined Browser-side registration is missing or loaded too late. Check the package README and confirm the command setup runs from the Cypress support file.
A task or preprocessor does not run Node-side code is not registered in the project’s event setup. Check setupNodeEvents and the package’s required event hooks.
Plugin setup fails after a Cypress upgrade The installed package may not support the Cypress version in use. Compare the installed versions with the directory listing and current package README; update or choose a compatible option.
Visual snapshots differ across runs The integration’s rendering environment, viewport, or baseline workflow may differ between runs. Confirm the documented capture environment and viewport, then review the tool’s baseline and approval process.
Accessibility scan passes but an issue remains The scan only detects issues covered by its rules and the state that was scanned. Review tool coverage, test additional states, and supplement with manual testing or Cypress assertions.
Reports are missing in CI The output location or artifact collection may not match the reporter configuration. Check the reporter’s current configuration, output format, and CI artifact collection steps.

6. ScreenshotNeo as a screenshot API alternative

If your need is to capture website screenshots as an API operation rather than add visual assertions to a Cypress test, try ScreenshotNeo first. It is a website screenshot API and MCP server from Yorker Media. A single GET request returns PNG, JPEG, WebP, or PDF. It is a separate workflow from Cypress plugins and does not replace test assertions or visual-baseline review.

For ScreenshotNeo’s available parameters and setup, see the API documentation.

cURL

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

Python

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)

Node.js

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
const bytes = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', bytes));

ScreenshotNeo accepts cookie and consent banners like a visitor, then removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture. Each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed; response headers identify the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients.

There is a free plan with 1,000 screenshots a month and no card. Paid plans start at $5 for 3,000 screenshots; every feature is on every plan, and yearly billing gives two months free. Sign up for 1,000 free screenshots a month, no card required.

7. Performance, reliability, and cost

Plugin costs vary by package and, for hosted visual testing or Cypress Cloud, by the service’s current plans and limits. The research here does not establish vendor pricing, so check current pricing with each provider rather than relying on an old comparison. Also account for CI execution, hosted rendering, artifact storage, and the maintenance time needed to keep integrations compatible.

Reliability starts with compatibility and configuration: pin and review dependency updates, confirm behavior in CI, and make sure the project can still run if a reporting or external visual service is unavailable. For screenshot comparisons, keep capture conditions and baseline review practices aligned with the integration’s documentation. Do not treat a package’s update date alone as a quality or security guarantee.

8. FAQ

Are Cypress plugins all maintained by Cypress?

No. The directory includes official, community, and deprecated entries. Community entries are owned by their communities and are not reviewed by Cypress.

Does an accessibility plugin certify a site as accessible?

No. Automated scans cover selected rules and states. Use the tool’s coverage information and add other testing where needed.

Is a visual testing service the same as a Cypress plugin?

It may integrate with Cypress, but it can also rely on a hosted service and its own baseline workflow. Check the integration requirements and review process.

Should I install several plugins at once?

Add integrations to address concrete needs. Each package brings configuration and compatibility to maintain, so adopt them incrementally and verify the suite after each addition.

Sources