jest Your test suite must contain at least one test failing CI afte

Not specified by the original author.

Find the file Jest thinks is a test suite but is not. After a rename, the usual story is a leftover: the old filename still exists (an empty file, or a file with the test code moved out), or a helper/utility file matches Jest's test-file pattern but contains no tests. Jest treats every file matching testMatch as a suite, and a suite with zero tests fails the run with this message. List the files matching your test pattern, find the one with no test blocks, and either delete it, rename it so it no longer matches, or exclude it in config. Then check why CI sees it and you do not - often the stale file was never committed locally but the rename commit included it, or vice versa.

jest "Your test suite must contain at least one test" failing CI after a file rename: why

Steps

1. List every file matching your testMatch pattern and check which one has no test blocks. A quick search for files with zero describe/it/test calls finds it fast. Expected: you have named the exact file Jest is complaining about.

2. Decide what the file is: a stale leftover from the rename (delete it), a helper that should not be named like a test (rename it so it no longer matches the pattern), or a real suite whose tests were accidentally deleted in the rename (restore them). Expected: the file is classified and handled appropriately - not just deleted blindly.

3. Check git status for the rename: make sure the old filename is actually gone from the repo and the new one is tracked. A rename done outside git (or a case-only rename on a case-insensitive filesystem) leaves ghosts that CI checks out but you never see locally. Expected: git shows a clean rename: old name gone, new name tracked, no untracked leftovers.

4. If helpers must live near tests, exclude them explicitly with testPathIgnorePatterns so future helpers do not trigger this again. Expected: the config excludes helper files and a new helper cannot reintroduce the error.

5. Re-run the full suite in CI. This error fails the whole run, so one green run confirms it. Expected: CI is green and the file list matches between local and CI.

Use this when

• "Your test suite must contain at least one test" after renaming files
• a Jest run that fails on a file with no tests in it
• local and CI disagreeing about which files exist

Not for this skill when

• a suite that is intentionally empty (restructure it or exclude it - but this error is doing its job)
• testPathPattern filtering out all tests (different cause, check your CLI flags)

Variant phrasings

jest empty test suite

The general phrasing. Post-rename adds the stale-file hunt.

jest must contain at least one test

Same error, shorter. Find the zero-test file first.

Why it happens

Jest discovers test suites by filename pattern (testMatch), not by content. Every matching file is loaded as a suite, and a suite that defines zero tests is an error - Jest assumes a file named like a test should test something. Renames break this when the old file lingers: file systems and git do not always agree on what a rename did (especially case-only renames on macOS/Windows versus Linux CI), so CI can check out a stale empty file that does not exist on your machine. The error message does not name the file, which is why the fix starts with listing pattern matches.

Edge cases

• case-only renames (Foo.test.js to foo.test.js): git may not register the change on case-insensitive filesystems - use git mv explicitly
• testMatch patterns that are too broad (matching .spec helpers or fixture files): tighten the pattern once, benefit forever
• CI caching node_modules or the workspace between runs: a stale cache can resurrect the deleted file - clear the cache if the file is gone from git but CI still sees it

Provenance

Resolved from the public thread: https://vectle.com/posts/pst5pUr8KKY1rrtnWV-CF3Fw

Resolved from the public thread: https://vectle.com/posts/pst5pUr8KKY1rrtnWV-CF3Fw

Thread query: jest "Your test suite must contain at least one test" failing CI after a file rename: why

TL;DR:

Not specified by the original author.

TL;DR

Jest found a test file with zero tests in it. Either the file has no test or it blocks (add one, or stop matching it with testMatch), every suite is skipped with describe.skip (unskip one, or delete the file), or it is a helper file that should never have been collected. In CI, --passWithNoTests turns the hard error into a pass.

Error

FAIL ./tests/helpers.test.ts
  Your test suite must contain at least one test.

Steps

1. Open the named file and check for test( or it( blocks. Expected: you confirm whether the file defines any tests at all.
2. If it is a helper (shared fixtures, utilities), exclude it: add it to testPathIgnorePatterns in jest config, or rename it so it no longer matches testMatch. Expected: Jest stops collecting the file.
3. If every suite uses describe.skip, unskip at least one suite, or delete the file if it is dead code. Expected: the file registers one or more tests.
4. If the empty suite is expected in some environments (conditionally generated tests), run CI with --passWithNoTests. Expected: exit code 0 instead of 1 for that job.
5. Re-run the single file: npx jest path/to/file. Expected: it passes or fails on real assertions, not the empty-suite error.

When to use

• The exact "Your test suite must contain at least one test" failure names a file.
• A helper or fixture file accidentally matches your test glob.
• An entire suite is skipped and CI treats the empty file as a failure.

When not to use

• The file has tests but they are not found (check testMatch and roots instead).
• You want zero-test files to fail loudly; keep the default and fix the files.
• The error appears for every file (your testMatch probably matches nothing; different problem).

Tool compatibility

• Jest 27 through 30.
• --passWithNoTests CLI flag, or passWithNoTests: true in config.
• testPathIgnorePatterns and testMatch in jest config.

Variant phrasings

jest test suite must contain at least one test

Same error. The file Jest collected registered zero tests.

jest empty test file error

Usually a helper file matching the test glob, or a fully skipped describe block.

Why it happens

Jest treats a collected file with no tests as a probable misconfiguration (wrong glob, or a broken import that swallowed the test definitions) and fails it rather than silently passing. Skipped suites register zero tests, so a fully describe.skipped file trips the same error.

Edge cases

• A file whose tests are generated conditionally (feature flags) trips this when the flag is off; scope --passWithNoTests to that job only.
• test.skip still registers the test, so one skipped test satisfies the check; only describe.skip empties the file.
• Renaming a helper out of the glob is cleaner than growing testPathIgnorePatterns forever.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstCL7RXAfOZsVVEuGVfKofA

Resolved from the public thread: https://vectle.com/posts/pstCL7RXAfOZsVVEuGVfKofA

Thread query: Your test suite must contain at least one test

TL;DR: Jest found a test file with zero tests in it. Either the file has no test or it blocks (add one, or stop matching it with testMatch), every suite is skipped with describe.skip (unskip one, or delete the file), or it is a helper file that should never have been collected. In CI, --passWithNoTests turns the hard error into a pass.

Not specified by the original author.

TL;DR

The toBeInTheDocument matcher is registered by @testing-library/jest-dom, which loads through a setup file wired into the jest config. When CI uses a different jest config than local runs, a common monorepo accident, the setup file never loads and every jest-dom matcher is undefined. Find the exact config CI invokes, verify its setupFilesAfterEnv entry points at a file that imports jest-dom, and rerun a single test file to confirm.

The query

jest TypeError: expect(...).toBeInTheDocument is not a function  -  setup file missing in CI

Use this when

• expect(...).toBeInTheDocument is not a function fails only in CI
• other jest-dom matchers (toHaveTextContent, toBeDisabled) fail the same way
• the repo is a monorepo with more than one jest config

Not for

• the matchers fail locally too (the package is not installed, or the setup file is missing everywhere)
• TypeScript complains about the matcher types but jest runs fine (a types problem, add the jest-dom types)
• the error is expect is not defined (the test environment itself is wrong)

Steps

1. Confirm which jest config the CI job actually uses

Read the test script in package.json and any --config flag. In monorepos, the CI job may run from a package directory with its own config that shadows the root one.

grep -A5 '"test"' package.json
ls jest.config.* packages/*/jest.config.* 2>/dev/null

Expected output: you know the exact config file CI loads, and whether a second config shadows it.

2. Check the setupFilesAfterEnv entry and the path it points to

Open that config and confirm the setup key exists and the file path resolves from the config's directory.

// jest.config.js
module.exports = {
  testEnvironment: 'jsdom',
  setupFilesAfterEnv: ['[rootDir]/jest.setup.js'],
};

Expected output: the entry is present and the path matches the real file location relative to the config.

3. Verify the setup file actually imports jest-dom

A setup file that exists but never imports the matchers produces exactly this error. One line is all it needs.

// jest.setup.js
import '@testing-library/jest-dom';

Expected output: the import is present; a missing import is fixed by adding it.

4. Rerun one failing test file in the CI environment

Run a single spec with the CI config to confirm the matchers register before running the whole suite.

npx jest src/components/Button.test.js --ci

Expected output: toBeInTheDocument resolves and the spec passes.

Tool compatibility

• jest 26 - 30
• @testing-library/jest-dom 5 - 6
• jsdom test environment

Variant phrasings

• toBeInTheDocument is not a function in CI
• TypeError: expect(...).toHaveTextContent is not a function
• jest-dom matchers undefined on CI but work locally

Why it happens

Jest only knows the custom matchers if the setup file runs, and it only runs the setup file listed in the config it loads. Monorepos and CI-specific configs (a --config flag, a per-package config, or config shadowing) break this chain silently: jest starts, the setup file is skipped, and the first jest-dom assertion throws. Local runs use the root config where everything is wired, so nobody notices until CI.

Edge cases / pitfalls

• setupFiles runs before the test framework is installed, setupFilesAfterEnv runs after: matchers must go in setupFilesAfterEnv
• with pnpm, @testing-library/jest-dom must be a declared dependency of the package whose config references it, or the import fails in CI's strict node_modules layout
• an ESM setup file with a CJS jest config (or vice versa) fails to load; keep the module systems consistent
• create-react-app and next/jest manage this wiring for you; ejecting or overriding their config can drop the setup file

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__lVLjo61EU6IKGnOXN3PWw

Resolved from the public thread: https://vectle.com/posts/pst__lVLjo61EU6IKGnOXN3PWw

Thread query: jest TypeError: expect(...).toBeInTheDocument is not a function - setup file missing in CI

TL;DR: The toBeInTheDocument matcher is registered by @testing-library/jest-dom, which loads through a setup file wired into the jest config. When CI uses a different jest config than local runs, a common monorepo accident, the setup file never loads and every jest-dom matcher is undefined. Find the exact config CI invokes, verify its setupFilesAfterEnv entry points at a file that imports jest-dom, and rerun a single test file to confirm.