How to Fix “No Tests Found” in Cypress 10.2.0

Cypress 10.2.0 shows “No tests found” when it opens the selected file but cannot find runnable test definitions in it. Start with the file contents, then check the effective specPattern, the file path and extension, any --spec filter, and—if you use Cucumber—the feature syntax and preprocessor. Cypress’s “No tests found” message is different from an error preparing a test file: preparation errors usually point to compilation, bundling, syntax, missing files or dependencies.

1. Confirm the selected file contains a test

Open the exact file named by Cypress and look for a real test block such as it() or a valid framework equivalent. An empty file or an empty suite cannot produce a runnable test.

describe('login', () => {
  it('shows the login form', () => {
    cy.visit('/login')
    cy.get('form').should('be.visible')
  })
})

Check these details before changing configuration:

The file is saved and is not zero bytes.
The test block is not commented out or hidden behind a condition that never runs.
The file uses Cypress commands in a valid test or suite callback.
You are opening the same file that the command line or runner selected.

2. Check the Cypress 10 configuration migration

Cypress 10 replaced the old testFiles option with specPattern. The pattern belongs inside the test type you are running: e2e or component. A legacy project may still contain integrationFolder, componentFolder or testFiles entries from Cypress 9.

Valid E2E configuration shape

const { defineConfig } = require('cypress')

module.exports = defineConfig({
  e2e: {
    specPattern: 'cypress/e2e/**/*.cy.{js,jsx,ts,tsx}',
  },
})

Valid component configuration shape

const { defineConfig } = require('cypress')

module.exports = defineConfig({
  component: {
    specPattern: '**/*.cy.{js,jsx,ts,tsx}',
  },
})

Do not put specPattern at the configuration root. Do not keep using testFiles as the Cypress 10 discovery setting. If Cypress reports a configuration load-time error about those options, fix the configuration structure before investigating the test body.

3. Compare the real path, filename and extension with specPattern

The configured glob must admit the file. Cypress’s documented E2E convention uses a .cy. infix:

File	Matches the default E2E convention?	Reason
`cypress/e2e/login.cy.js`	Yes	Expected directory, infix and extension
`cypress/e2e/login.js`	No	Missing `.cy.` in the filename
`tests/login.cy.ts`	Not unless configured	Outside the default E2E directory
`cypress/e2e/login.feature`	Not with the JavaScript default	Extension is not included

Either move the spec into the configured directory or change the pattern to match your layout. Match the extension you actually use: JavaScript, JSX, TypeScript or TSX. For a custom layout:

const { defineConfig } = require('cypress')

module.exports = defineConfig({
  e2e: {
    specPattern: 'tests/cypress/**/*.cy.js',
  },
})

4. Treat –spec as a filter, not a replacement

The --spec argument narrows the files Cypress already admitted through specPattern. It cannot select a file outside that pattern. The path should be relative to the project folder.

npx cypress run --e2e --spec cypress/e2e/login.cy.js

If this command reports no tests, verify both sides:

The file exists at the exact relative path.
The path matches the E2E specPattern.
The extension is included by the glob.
The file contains at least one test definition.

For a file in a custom directory, update the configuration first:

const { defineConfig } = require('cypress')

module.exports = defineConfig({
  e2e: {
    specPattern: 'tests/**/*.cy.js',
  },
})

npx cypress run --e2e --spec tests/login.cy.js

5. Inspect Cypress discovery with DEBUG logging

When the path appears correct but Cypress still finds nothing, enable the documented discovery logs:

DEBUG=cypress:cli,cypress:data-context:sources:FileDataSource,cypress:data-context:sources:ProjectDataSource npx cypress run --e2e

Use the output to identify the project directory, resolved configuration, discovered files and the effect of your --spec argument. This is especially useful when a monorepo, shell working directory or CI job points Cypress at a different project than expected.

6. Check Cucumber feature syntax and preprocessing

If your specs are .feature files, discovery depends on both the configured glob and the Cucumber preprocessor. A reported Cypress 10.2.0 case used specPattern: "**/*.feature" and a feature beginning with the plural keyword Scenarios:. The accepted fix was to use the singular Gherkin keyword Scenario:.

Feature: Login

  Scenario: A user can sign in
    Given the login page is open
    When valid credentials are submitted
    Then the dashboard is displayed

Treat this as a case-specific clue, not a universal explanation. Confirm that the feature parser accepts the syntax, that the preprocessor is installed and configured, and that the feature is converted into Cypress tests.

7. Separate discovery failures from preparation failures

These messages indicate different diagnostic paths:

Message or phase	What it usually means	What to inspect
No tests found	Cypress opened the selected file but found no runnable test definitions.	Test blocks, path, filename, extension, specPattern and Cucumber syntax
Error preparing your test file	Cypress could not compile or bundle the file.	Syntax errors, missing dependencies, missing files and preprocessor output

Do not try to fix a bundling error by changing only the test glob. Read the full preparation message and repair the reported compile, dependency or path problem.

8. A complete diagnostic checklist

Copy the exact selected spec path from the Cypress runner or command output.
Open that file and confirm it contains an it(), specify() or valid framework test.
Identify whether you are running E2E or component testing.
Open cypress.config.js, cypress.config.ts or the project’s equivalent.
Check e2e.specPattern or component.specPattern, depending on the test type.
Remove or migrate Cypress 9 options such as testFiles, integrationFolder and componentFolder.
Compare directory, filename infix and extension with the effective glob.
Remove --spec temporarily to see whether Cypress discovers any files at all.
If using Cucumber, validate the feature keyword, parser and preprocessor.
If the message says preparation failed, follow the compilation or bundling error branch instead.
Run with the Cypress DEBUG namespaces to inspect file resolution.

9. Common errors and fixes

Cause: The default E2E pattern expects a .cy. infix.

Fix: Rename it to login.cy.js or change specPattern to include the naming convention you use.

specPattern is at the top level

Cause: Cypress 10 expects the pattern inside e2e or component.

Fix: Move it under the test type being run.

testFiles still appears in the config

Cause: The project has not completed the Cypress 9 to Cypress 10 migration.

Fix: Replace it with the corresponding nested specPattern and place files under the matching directory.

–spec points to a valid file but Cypress still finds nothing

Cause: The file exists but is outside the configured pattern. Cypress intersects the CLI filter with the configured discovery set.

Fix: Update specPattern or move the file, then rerun the command.

The feature file uses Scenarios:

Cause: In the reported Cypress 10.2.0 Cucumber case, the parser expected the singular keyword.

Fix: Change it to Scenario: and verify the preprocessor output.

The error says Cypress could not prepare the file

Cause: This is a compile or bundle failure rather than a test-discovery failure.

Fix: Inspect the complete error for syntax problems, missing dependencies, missing files or preprocessor configuration.

10. Performance, reliability and CI considerations

Discovery problems often appear only in CI because the command runs from a different working directory or uses a different Cypress configuration. Make the project directory explicit in CI, keep the test type explicit, and use a path relative to that project when passing --spec.

Broad globs make configuration easier to evolve, while narrow globs reduce accidental matches. Choose a pattern that reflects the repository layout and keep the filename convention consistent. When changing from Cypress 9, migrate configuration and file locations together so the resolved pattern and actual files do not drift apart.

For reliable diagnosis, record the Cypress version, test type, resolved configuration, selected path, command line and full error text. Current Cypress documentation may describe defaults from releases after 10.2.0, so verify the project’s own resolved settings when exact historical behavior matters.

11. Or skip the browser setup

If your goal is to capture a page image for test evidence, visual documentation or a CI artifact rather than run Cypress itself, ScreenshotNeo provides a single screenshot request. Its API accepts a URL and returns PNG, JPEG, WebP or PDF; the options include custom JavaScript and CSS, waiting rules, device presets, full-page capture and element selection. See the ScreenshotNeo API documentation.

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

Cookie and consent banners, newsletter popups and chat widgets are removed before the shot. Bot checks, blank pages and failed loads are never billed, and response headers identify the page verdict and whether it was billed. ScreenshotNeo also provides an MCP server so Claude, Cursor and other MCP clients can use take_screenshot, get_page_info and capture_pdf. The Free plan includes 1,000 screenshots each month with no card; paid plans start at $5 for 3,000 shots.

Create a free ScreenshotNeo account and get 1,000 screenshots per month with no card.

12. FAQ

Does –spec override specPattern?

No. It filters the files already admitted by specPattern.

Can an empty describe block trigger this message?

Yes. Cypress needs a runnable test definition inside the selected file.

Should specPattern be shared by E2E and component tests?

Configure it under the test type being run. E2E and component projects can use different patterns.

Is every Cucumber “No tests found” error caused by Scenarios:?

No. That was the fix in one reported Cypress 10.2.0 case. Check the parser and preprocessor for the actual project.

What information is needed to identify the exact cause?

The Cypress version, test type, configuration, selected file path and contents, command line, preprocessor settings and complete error output.