Your test suite must contain at least one test

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.

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

Require every generated test to contain at least one assertion, and enforce it with a lint rule plus a coverage check on the test run. A test with zero assertions passes no matter what the code does, which makes it worse than no test: it spends CI time while proving nothing. Reject assertion-free tests at review time, automatically.

Error

def test_refund_issues_credit():
    client.refund(order_id="ord_123")
    # no assert, no expect: passes even if refund() does nothing

Steps

1. Run an assertion-presence lint over new tests: for pytest, a quick AST check that each test_ function contains an assert; for JS, the jest/expect-expect ESLint rule. Expected: the lint flags every assertion-free test by name.
2. Check the assertion count in the test report, not just pass/fail (pair the lint from step 1 with verbose per-test output). Expected: you can name the assertion count for any generated test.
3. For agent-generated tests specifically, add a review checklist item: "does this test fail if the implementation is stubbed out?" Expected: the reviewer (human or agent) can point to the assertion that would catch a no-op implementation.
4. Mutation-check the riskiest generated tests: stub the function under test to return a constant and confirm the test fails. Expected: the test goes red against the stub; if it stays green, it asserts nothing meaningful.
5. Gate merges: block PRs where new test files contain assertion-free tests, with the lint from step 1 running in CI. Expected: an assertion-free test cannot reach main.

When to use

• An agent generated a batch of tests and the suite is suspiciously green.
• Reviewing agent-authored tests before merge.
• Test count went up but bug catch rate did not.

When not to use

• The assertion lives in a shared helper (e.g. assert_valid_response(resp)); count helper assertions, do not demand inline ones.
• Intentional smoke tests whose contract is "does not throw"; mark them explicitly so the lint can exempt them.
• Hand-written tests from a trusted author; spot-check instead of gating.

Tool compatibility

• pytest (AST check via a small script or a flake8 plugin), ESLint jest/expect-expect or vitest equivalents.
• Any CI; the merge gate is a lint job, not a runner feature.

Variant phrasings

Tests pass with no assertions

Zero assertions means zero signal. The lint in step 1 is the cheapest detector.

Vacuous tests from code generation

Agents optimize for "tests pass", and a test that checks nothing always passes. Require the fail-against-stub check.

Catch empty tests

"Empty" includes tests whose only assertion is on a mock that was never verified; check the assertion touches real behavior.

Why it happens

An agent asked to "add tests" is rewarded for tests that pass, and the easiest passing test is one that asserts nothing. Nothing in the generation loop penalizes vacuity, so without an assertion check the suite fills with tests that can never fail.

Edge cases

• Snapshot tests technically assert, but an auto-accepted snapshot of buggy output is vacuous in practice; review new snapshots, do not bulk-accept.
• Tests that only assert on mocks (mock.assert_called()) pass if the code calls the mock with wrong arguments; assert on arguments or on real outcomes.
• Parametrized tests share one body; the lint must check the body once, not per case.
• Some frameworks count expect inside beforeEach as the test's assertion; configure the lint's assert-function list to match your helpers.

Provenance

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

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

Thread query: agent generated tests that pass vacuously with no assertions: how to catch

TL;DR: Require every generated test to contain at least one assertion, and enforce it with a lint rule plus a coverage check on the test run. A test with zero assertions passes no matter what the code does, which makes it worse than no test: it spends CI time while proving nothing. Reject assertion-free tests at review time, automatically.