ScreenshotNeo

BlogHow-to

How to Run All Cypress Specs in One Run

Run every Cypress spec discovered by your project with `npx cypress run`. Learn how configuration, filters, CI parallelism, and common errors affect the result.

By the ScreenshotNeo team4 October 20266 min read

From your Cypress project root, run:

npx cypress run

This runs Cypress tests to completion, headlessly by default, for the specs discovered by the project’s configuration and selected testing type. It does not mean every file anywhere on disk. Leave out --spec when you want the full configured suite. [Cypress CLI reference]

Run the full suite from the command line

  1. Open a terminal in the project that contains cypress.config.js, cypress.config.ts, or another supported Cypress configuration file.
  2. Run npx cypress run. If Cypress is a project dependency, npx invokes that project version.
  3. Review the terminal summary and exit code. A nonzero exit code means the run did not complete successfully, even if some specs passed.

Equivalent package-manager commands documented by Cypress include:

yarn cypress run
pnpm cypress run
bunx cypress run

The command runs the configured testing type in headless mode by default. E2E and Component Testing have separate configuration and spec discovery, so check which type your project is set up to run. [CLI reference]

What “all specs” means

Cypress discovers specs according to the active testing type’s specPattern and excludes matching files in excludeSpecPattern. A CLI --spec selection further narrows the eligible set; a selected file still has to match specPattern. Thus, the full suite means every spec eligible under the current project configuration, not every JavaScript or TypeScript file in the repository. [Cypress configuration reference]

For the entire discovered suite, avoid adding --spec. These are examples for intentionally running a subset:

# One spec
npx cypress run --spec "cypress/e2e/login.cy.js"

# A matching folder or glob
npx cypress run --spec "cypress/e2e/login/**/*"

Quote glob patterns so the shell does not expand them differently before Cypress receives them.

Run all specs in CI, sequentially or in parallel

One machine

Use npx cypress run in the CI job to run the configured suite on that machine. This is the simplest setup and does not require Cypress Cloud recording. Ensure the job starts in the project directory and does not append a --spec filter.

Multiple CI machines

To distribute a recorded run across CI machines, Cypress documents this form:

npx cypress run --record --parallel

This workflow requires a recorded run and multiple CI machines configured with the provider. Cypress distributes whole spec files, and their execution order is not guaranteed. Parallel mode is a CI workflow, not a way to make one local invocation use several local processes. [Cypress parallelization] [Cypress Cloud setup]

Specs that take very different amounts of time can leave a machine waiting for a long-running spec on another machine. Cypress also documents fixed browser, support-file, and application reload overhead per spec. Keep specs isolated and sensibly sized: extremely large files can limit balancing, while many tiny files incur repeated setup overhead. [Cypress test performance]

Runner UI: Run All Specs

The desktop Runner has a separately documented experimental experimentalRunAllSpecs option for running multiple specs sequentially from its UI. It is disabled by default and is not needed for the standard command-line suite. Use the CLI command when the goal is a repeatable local or CI run. [Cypress experiments reference]

When some specs do not run

  1. Check the working directory. Run from the intended project root, or specify the project with --project if launching from elsewhere.
  2. Inspect specPattern. Confirm the file paths for the active testing type match the pattern. Passing a path with --spec does not bypass this configuration.
  3. Inspect excludeSpecPattern. A matching file is removed from discovery even if it otherwise fits the spec pattern.
  4. Remove accidental filters. Check package scripts and CI definitions for an inherited --spec argument.
  5. Confirm the testing type. E2E and Component Testing use their respective configuration and discovery settings.
  6. Check the command actually used. A script may call Cypress with different flags than the command you expect; print or inspect the resolved script and CI step.

Common errors and fixes

Symptom Likely cause Fix
No specs found Wrong project directory, wrong testing type, or a pattern that matches no files. Run in the project root; verify the active specPattern and testing type.
A named spec is not included The file is outside specPattern or matches excludeSpecPattern. Correct the path or configuration, then rerun without a restrictive --spec if you want the complete suite.
Only a few specs run A package script, shell command, or CI step supplies --spec. Remove or broaden that filter and rerun the ordinary full-suite command.
Specs run in an unexpected order Parallel Cloud runs distribute files, and order is not guaranteed. Do not make tests depend on spec order; keep setup and cleanup independent.
Local run is slower than expected One machine is executing the suite, and per-spec startup and reload work adds overhead. Review slow specs and setup costs. For CI speed, consider the documented recorded parallel workflow with multiple machines.

Speed, reliability, and cost considerations

  • Local execution: the basic command runs on the current machine. Runtime depends on the specs, application, browser, and machine; there is no universal duration.
  • CI execution: parallelization can shorten a suite when enough work exists across spec files and machines, but requires Cloud recording and CI setup. A single long spec can limit how well work is distributed.
  • Reliability: do not rely on spec ordering, especially for parallel runs. Each spec should set up the state it needs and leave other specs unaffected.
  • Cost: the local command itself does not require Cloud parallelization. The documented multi-machine route involves Cypress Cloud; check its current plan and usage terms before adopting it, since this guide does not establish current pricing.

Cypress’s performance guide includes a Kitchen Sink example that went from 1:51 on one machine to 59 seconds on two machines. That is an example for that project and setup, not a runtime guarantee. [Cypress test performance]

Or skip the browser setup

If your next step is capturing a page screenshot for a test artifact, visual review, or documentation, ScreenshotNeo can return an image or PDF from one API request. It is a screenshot API and MCP server from Yorker Media. The Cypress command above runs Cypress specs; this API call captures a website page, so it does not replace running the test suite.

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}`);

See the ScreenshotNeo API documentation for request options. Cookie banners are accepted like a visitor and more than 60 known consent platforms, newsletter popups, and chat widgets are removed before capture; those steps can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits cost nothing, with page verdict and billing information in response headers. An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 shots.

Sign up free for 1,000 screenshots a month, with no card required.

FAQ

Does npx cypress run open the interactive Test Runner?

No. The documented CLI run completes tests headlessly by default. Use the Cypress app when you need its interactive Runner.

Should I pass --spec to run everything?

No. --spec selects files and narrows the run. Omit it for all specs Cypress discovers under the project configuration.

Can I run all specs in parallel on my laptop with that command?

The documented --parallel workflow coordinates recorded CI runs across multiple machines. The ordinary local command runs on the current machine.

Does a screenshot API run Cypress tests?

No. ScreenshotNeo captures a page as an image or PDF. Use Cypress to execute and assert on your application’s tests.