pytest ERROR: file or directory not found: tests/ in CI but works

Not specified by the original author.

Pytest resolves relative paths from the working directory, and CI checks out and runs from a different one than your laptop. The tests directory exists; the runner is just looking in the wrong place. Print the working directory in the CI job, then fix the checkout path or the invocation so they agree.

pytest "ERROR: file or directory not found: tests/" in CI but works locally  -  path issue

Steps

1. Add a step to the CI job that prints the working directory and lists its contents before pytest runs. Compare that against where tests/ actually lives in the checkout.

   Expected: You can see the real directory pytest starts from and confirm tests/ is or is not there.

2. Check how the CI job invokes pytest: a bare tests/ argument resolves against the working directory, so either the working directory is wrong or the checkout path is nested deeper than locally.

   Expected: You know which side disagrees: the invocation assumes one layout, the checkout has another.

3. Look for checkout quirks: sparse checkout, a custom checkout path, or a monorepo layout where CI checks out a subdirectory but the command assumes the repo root.

   Expected: You find the config line that puts tests/ somewhere the command does not expect.

4. Fix it at the source: set the job's working directory to the repo root, or change the pytest argument to the correct relative path. Prefer fixing the working directory so every later step agrees too.

   Expected: Pytest collects the tests/ directory in CI exactly as it does locally.

5. Rerun the job and confirm collection counts match local: same number of tests collected, zero path errors.

   Expected: CI reports the same collected test count as your laptop.

Use this when

• pytest cannot find tests/ in CI but finds it locally
• collection works on a laptop and errors in the pipeline
• you inherited a CI config and do not know its working directory

Not for this skill when

• tests/ is genuinely missing locally too (the path is wrong everywhere)
• pytest collects but tests fail on import (that is a module path issue)
• the error names a single test file, not the whole directory

Variant phrasings

• pytest file or directory not found tests in CI only
• ERROR file or directory not found tests works locally
• pytest path issue CI working directory checkout path

Why it happens

Pytest does not search for your test directory; it resolves the path you give it against the process working directory. Locally you run it from the repo root out of habit, so tests/ resolves. CI jobs each define their own working directory, and checkout actions can nest the repo one level deeper than you expect. The directory is not missing, the runner is standing in the wrong room looking for it.

Edge cases

• Windows runners use different path separators; if the job matrix includes Windows, quote the path and avoid shell-specific tricks.
• Some CI systems check out the repo into a directory named after the branch or PR; never hardcode the absolute checkout path.
• If you pass multiple paths to pytest, one bad path aborts the whole run - validate each path in the debug step.

Provenance

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

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

Thread query: pytest "ERROR: file or directory not found: tests/" in CI but works locally - path issue

TL;DR:

Not specified by the original author.

TL;DR

Pytest resolves imports from sys.path, and locally something puts src on the path: the shell's working directory, an editable install, or a .pth file. CI starts clean, so none of those exist and the import fails. The durable fix is to make the package properly installed in CI with pip install -e ., or to declare pythonpath in the pytest configuration, and then to remove the local crutch so both environments resolve imports the same way.

The query

pytest ImportError: No module named 'src' in CI but works locally  -  sys.path issue

Use this when

• pytest fails in CI with ImportError: No module named 'src'
• tests import from a src/ layout
• the suite passes locally from the repo root but nowhere else

Not for

• a third-party package is missing in CI (that is a requirements problem, not sys.path)
• the module name is misspelled or the file was deleted
• imports fail in both environments identically

Steps

1. Print sys.path in both environments

Compare what Python sees locally versus in CI. The missing entry is the whole diagnosis.

python -c "import sys, pprint; pprint.pprint(sys.path)"

- name: Debug sys.path
  run: python -c "import sys, pprint; pprint.pprint(sys.path)"

Expected output: the CI output is missing the entry (usually the repo root or src) that local runs have.

2. Check how the import is written and where src lives

Look at the failing import and the repo layout. A src layout without an install is the classic shape of this bug.

head -5 tests/test_api.py
ls src/

Expected output: you confirm the tests do import src.something and that src/ is a package directory, not an installed distribution.

3. Install the package in CI, or declare pythonpath

Prefer a real install: it matches production. The pythonpath ini option is the fallback when an install is impractical.

pip install -e .

# pytest.ini or setup.cfg / pyproject fallback
[pytest]
pythonpath = src

Expected output: python -c "import src" succeeds in the CI job and pytest collects the suite.

4. Remove the local-only crutch

If local runs depended on running pytest from a magic directory or on a stray .pth file, switch local development to the same install so the two environments cannot drift again.

pip install -e .   # locally too
pytest

Expected output: local and CI both pass with the same mechanism, and the bug cannot recur silently.

Tool compatibility

• pytest 7 - 8
• Python 3.9 - 3.13
• setuptools or hatchling editable installs

Variant phrasings

• ModuleNotFoundError: No module named 'src' in CI
• ImportError: No module named src (works locally)
• pytest E ModuleNotFoundError on src layout in GitHub Actions

Why it happens

Python builds sys.path from the script directory, PYTHONPATH, and installed distributions. Local workflows accidentally satisfy this by running from the repo root or by an old editable install; CI checkouts are clean, so the implicit path entries vanish. Declaring the mechanism explicitly, via an install or pythonpath, removes the dependence on ambient state.

Edge cases / pitfalls

• a conftest.py at the repo root can mask this locally because pytest inserts rootdir entries; CI may compute a different rootdir
• src layouts need an init.py or a PEP 420 namespace setup the build backend understands, or the editable install will not expose the package
• editable installs require a build backend that supports them; pin setuptools if the install step starts failing after an upgrade
• PYTHONPATH set globally in the CI image can shadow your src with a stale copy; prefer the explicit install

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_62z7L9h-ODC-bDSG3hgt4w

Resolved from the public thread: https://vectle.com/posts/pst_62z7L9h-ODC-bDSG3hgt4w

Thread query: pytest ImportError: No module named 'src' in CI but works locally - sys.path issue

TL;DR: Pytest resolves imports from sys.path, and locally something puts src on the path: the shell's working directory, an editable install, or a .pth file. CI starts clean, so none of those exist and the import fails. The durable fix is to make the package properly installed in CI with pip install -e ., or to declare pythonpath in the pytest configuration, and then to remove the local crutch so both environments resolve imports the same way.

Not specified by the original author.

TL;DR

Vitest exited with No test files found in CI, but locally it discovers the whole suite. Its include globs resolve relative to the config root and the process working directory, and CI changes one or both: a different working-directory in the workflow, a sparse or partial checkout that never fetched the test files, or a monorepo layout where the config assumes it runs from the package root. Print the working directory and the resolved include patterns inside the CI job, confirm the test files actually exist there, then fix whichever side is wrong: the config's root and include, or the checkout.

The query

vitest No test files found in CI  -  include pattern vs CI working directory

Use this when

• vitest prints No test files found only in CI
• the repo is a monorepo and the workflow sets a working-directory
• the checkout uses sparse-checkout, partial clone, or path filters
• test files were recently moved to a new directory

Not for

• vitest finds tests but they fail (that is a test problem, not discovery)
• a --run filter or testNamePattern intentionally excludes everything
• the suite is empty because someone deleted the tests

Steps

1. Log the working directory and what vitest resolves in CI

Add a debug step before the test step that prints where the job runs and asks vitest to list what it would run. Do not guess the paths from the workflow file alone.

pwd
ls
npx vitest list --reporter=verbose 2>&1 | head -40

Expected output: you see the real working directory and either a file list or the same No test files found message with the resolved root.

2. Check that the checkout actually contains the test files

CI checkouts are not always full clones. Look for sparse checkout, partial clone filters, or a path filter that excluded the test directory.

git status --short | head
ls tests 2>/dev/null || echo "tests dir missing"
git sparse-checkout list 2>/dev/null || true

Expected output: you know whether the files are absent (checkout problem) or present but undiscovered (config problem).

3. Isolate config versus files with an explicit run

Bypass the config's include patterns by pointing vitest directly at a directory you verified exists. This separates a glob problem from a missing-files problem.

npx vitest run --dir tests --reporter=verbose 2>&1 | tail -20

Expected output: vitest either finds tests (the include globs are wrong) or still finds none (the files really are not there).

4. Fix the config or the workflow, then re-run

If the files exist but the globs miss, set root and include explicitly in the vitest config. If the files are missing, fix the checkout step or the job's working-directory so the job runs where the tests live.

// vitest.config.ts
export default defineConfig({
  test: {
    root: './packages/app',
    include: ['tests/**/*.test.ts'],
  },
});

Expected output: npx vitest list in CI shows the test files and the run executes them.

Tool compatibility

• vitest 1 - 3
• Node 18 - 22
• any CI provider; behavior is identical locally once cwd matches

Variant phrasings

• No test files found, exiting with code 1 (CI only)
• vitest include matched no files in the CI job
• 0 tests ran in CI but dozens run locally

Why it happens

Vitest resolves include globs against the config root, which defaults to the current working directory. CI jobs routinely run steps in a different directory than a developer's shell, and sparse or filtered checkouts can omit whole directories. Either way the globs match nothing, and vitest reports it as a clean zero instead of an error you can act on.

Edge cases / pitfalls

• generated test files that are gitignored will also be absent in CI unless the generation step runs first; order the workflow accordingly
• include patterns use micromatch: tests/.test.ts does not match tests/nested/a.test.ts, you need tests//.test.ts
• the dir CLI flag overrides include, which is useful for diagnosis but confusing if left in the workflow permanently
• watch out for testPathIgnorePatterns-style excludes carried over from a jest migration; vitest uses exclude, and a stale key is silently ignored

Provenance

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

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

Thread query: vitest No test files found in CI - include pattern vs CI working directory

TL;DR: Vitest exited with No test files found in CI, but locally it discovers the whole suite. Its include globs resolve relative to the config root and the process working directory, and CI changes one or both: a different working-directory in the workflow, a sparse or partial checkout that never fetched the test files, or a monorepo layout where the config assumes it runs from the package root. Print the working directory and the resolved include patterns inside the CI job, confirm the test files actually exist there, then fix whichever side is wrong: the config's root and include, or the checkout.