JavaScript tests are found only by file name (*.test.*, *.spec.*, __tests__/): the classic test/ directory with mocha, node --test, node:assert is "no tests"; jest via node ./node_modules/jest/bin/jest.js, borp, xo, nub are unknown runners

Offen
#254 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
35/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
javascript, node.js, python
Bereich
testing, tooling

Rechercherichtung

The JavaScript test and runner detection lives in ecosystems/javascript/init.py: the file-name regex near line 309, the _JS_RUNNERS set near line 311, and the _js_tests logic around lines 314-323. Start by reproducing one case from the issue, such as a test/index.js run by npm test, and check which branch rejects it. Done means the listed repros (mocha in test/, a node <path>/jest/bin/jest.js script, and borp) pass with fixtures and the existing tests still pass.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

express, got, mime-db (whose nyc coverage PASSes in the same run), octokit/graphql-schema: a test/ directory run by npm test → FAIL "no tests found". phoenix and actions/checkout run node --experimental-vm-modules ./node_modules/jest/bin/jest.js (Jest's documented ESM invocation) → "no CI runs jest … (or npm test)" although npm test was read. fastify runs borp (a node:test runner wrapping c8, with --check-coverage --lines 100), got runs xo (eslint wrapper, thousands of packages), zod runs everything through nub run <script>. ecosystems/javascript/__init__.py:309 should also take test/**/*.{js,ts} (and tests/) when a known runner or npm test runs, and match runners by the script they execute. Also: got's tsconfig extends a strict base, so the "enable strict" hint is wrong.

Evidence from the corpus audit

phoenixframework/phoenix / tests-run
  • kind: FALSE_NEGATIVE (MESSAGE)
  • actual: FAIL "JavaScript/TypeScript: tests found in 6 file(s), but no CI configuration runs jest, vitest, mocha,
    node --test, deno test, bun test or playwright (or npm test)"
  • expected: PASS for JavaScript: CI runs npm test, whose script runs Jest.
  • evidence: .github/workflows/ci.yml:151: run: npm test; package.json:35: "test": "node --experimental-vm-modules ./node_modules/jest/bin/jest.js"; jest.config.js:21: testRegex: "/assets/test/.*_test\\.js$". The facts show the
    script was expanded (Command origin package.json:scripts.test argv ["node","--experimental-vm-modules", "./node_modules/jest/bin/jest.js"]), but project_validator/ecosystems/javascript/__init__.py:314-323 only
    accepts program(argv) in {"jest","vitest","mocha","ava"} or node --test; a runner launched as
    node <path>/jest/bin/jest.js (the documented way to run Jest with ESM) is not recognised. The message's
    "(or npm test)" is also misleading: npm test was run and read.
  • repro: package.json {"scripts":{"test":"node --experimental-vm-modules ./node_modules/jest/bin/jest.js"}},
    a.test.js, workflow run: npm test
  • confidence: high
jshttp/mime-db / tests-run
  • kind: FALSE_NEGATIVE
  • actual: FAIL: no tests found (.test., .spec. or tests/ files)
  • expected: PASS: the mocha convention test/*.js run by npm test on 29 Node versions. The same run also credits
    nyc for coverage (PASS "branch coverage is reported with nyc"), which wraps npm test; a project with measured
    coverage and "no tests" is self-contradictory.
  • evidence: test/index.js:1-4: var assert = require('assert') ...; package.json:
    "test": "mocha --reporter spec --check-leaks test/", "test-ci": "nyc --reporter=lcovonly --reporter=text npm test";
    .github/workflows/ci.yml "Run tests" step: npm run test-ci / npm test; validator
    project_validator/ecosystems/javascript/__init__.py:309: path=re.compile(r"(?:^|/)(?:[^/]*(?:[._]test|\.spec)\.[^/]+|__tests__/.+)$").
  • repro: test/index.js with describe(/it( + "test": "mocha test/" + a step run: npm test.
  • confidence: high
actions/checkout / tests-run
  • kind: FALSE_NEGATIVE
  • actual: FAIL "JavaScript/TypeScript: tests found in 10 file(s), but no CI configuration runs jest, vitest, mocha,
    node --test, deno test, bun test or playwright (or npm test)".
  • expected: PASS: CI runs npm test, whose script is Jest's documented ESM invocation.
  • evidence: .github/workflows/test.yml:27: - run: npm test; package.json:12: "test": "node --experimental-vm-modules node_modules/jest/bin/jest.js". Validator: ecosystems/javascript/__init__.py:314-321:
    _js_tests accepts name in _JS_RUNNERS or (name == "node" and "--test" in argv); node <path>/jest.js matches
    neither, and npm test itself (named in the hint) is not credited when its script is unrecognised.
  • repro: package.json "test": "node --experimental-vm-modules node_modules/jest/bin/jest.js", src/a.test.ts,
    workflow run: npm test.
  • confidence: high
octokit/graphql-schema / tests-run
  • kind: FALSE_NEGATIVE
  • actual: FAIL: no tests found (*.test.*, *.spec.* or __tests__/ files)
  • expected: PASS: a test/ directory of node:assert tests runs on every push via npm test.
  • evidence: package.json:13: "test": "node test",; test/index.js:1-2: import "./smoke.js"; / import "./validate.js";; test/smoke.js:1-5: import { strict } from "assert"; ... strict.equal(typeof validate, "function");; .github/workflows/test.yml:20: - run: npm test
  • evidence (validator): ecosystems/javascript/init.py:307-309: name="*.test.*, *.spec.* or __tests__/ files" / path=re.compile(r"(?:^|/)(?:[^/]*(?:[._]test|\.spec)\.[^/]+|__tests__/.+)$"): a top-level test/ directory (mocha's and node's classic layout) is not a test location. npm test itself is accepted as a runner, so only the file pattern is missing.
  • repro: package.json with "test": "node test", test/index.js, workflow run: npm test.
  • confidence: high
expressjs/express, sindresorhus/got / tests-run
  • kind: FALSE_NEGATIVE
  • actual: FAIL: no tests found (*.test.*, *.spec.* or __tests__/ files) (both projects)
  • expected: PASS: both have a test/ directory of test files that CI runs through a known runner.
  • evidence:
    • express package.json:94: "test": "mocha --require test/support/env --reporter spec --check-leaks test/ test/acceptance/";
      package.json:95: "test-ci": "nyc --exclude examples --exclude test --exclude benchmarks --reporter=lcovonly --reporter=text npm test";
      .github/workflows/ci.yml:80: run: npm run test-ci; test/ holds 74 files (test/app.js, test/Router.js, ...)
    • got package.json: "test": "xo && tsc --noEmit && NODE_OPTIONS='--import=tsx/esm' node --test --test-timeout=60000 'test/*.ts'";
      .github/workflows/main.yml:26: - run: npm run test; test/ holds 43 .ts files (test/abort.ts, test/http.ts, ...)
    • validator: project_validator/ecosystems/javascript/__init__.py:309:
      path=re.compile(r"(?:^|/)(?:[^/]*(?:[._]test|\.spec)\.[^/]+|__tests__/.+)$") — nothing under test/ or tests/
      counts unless the file name itself says test. facts/roles.py:27 already maps test, tests, spec directories to
      the test role; the tests-run question does not use it. Note express's coverage check PASSes "branch coverage is
      reported with nyc" in the same run: the validator followed npm test to mocha for coverage but reports no tests (MESSAGE).
  • repro: package.json {"scripts":{"test":"mocha test/"}}, test/app.js with one describe, workflow step run: npm test.
  • confidence: high
fastify/fastify / tests-run, coverage
  • kind: UNSUPPORTED
  • actual: FAIL: tests found in 198 file(s), but no CI configuration runs jest, vitest, mocha, node --test, deno test, bun test or playwright (or npm test); coverage FAIL no branch coverage measurement found
  • expected: PASS: CI runs npm run unit -> borp (a node:test runner wrapping c8) and npm run coverage:ci-check-coverage -> borp --coverage --check-coverage --lines 100.
  • evidence: package.json:29: "unit": "borp"; package.json:16: "coverage:ci-check-coverage": "borp --reporter=@jsumners/line-reporter --coverage --check-coverage --lines 100";
    .github/workflows/ci.yml:85-87: - name: Run tests / run: | / npm run unit; .github/workflows/coverage-nix.yml (called from ci.yml:45): run: | / npm run coverage:ci-check-coverage;
    .borp.yaml:1-3: files: / - 'test/**/*.test.js'. Validator ecosystems/javascript/__init__.py:311: _JS_RUNNERS = frozenset({"jest", "vitest", "mocha", "ava"}).
    borp is used across the fastify organisation (and tap/node-tap is similarly absent). test:types -> tstyche (type tests) is also unknown to type-checking.
  • repro: package.json {"scripts":{"unit":"borp"}} + .borp.yaml + step run: npm run unit.
  • confidence: high (as a gap)
sindresorhus/got / static-analysis, compiler-warnings, warnings-as-errors
  • kind: UNSUPPORTED
  • actual: FAIL: no static analyzer runs; FAIL no JavaScript linters found; enable at least eslint
  • expected: PASS: xo (the eslint wrapper used by every sindresorhus package and thousands of others) runs in CI through npm run test, configured in package.json's xo key.
  • evidence: package.json: "test": "xo && tsc --noEmit && ...", "xo": [ { "ignores": [...] }, { "rules": { "@typescript-eslint/no-empty-function": "off", ... } } ];
    .github/workflows/main.yml:26: - run: npm run test.
  • repro: package.json {"scripts":{"test":"xo"},"xo":{}} + step run: npm test.
  • confidence: high (as a gap)
colinhacks/zod / tests-run, static-analysis, code-formatting
  • kind: UNSUPPORTED, MESSAGE
  • actual: FAIL: tests found in 203 file(s), but no CI configuration runs jest, vitest, ...; FAIL biome is configured (biome.jsonc, ...) but does not run; WARN biome.jsonc ... is defined but CI does not run ... biome
  • expected: PASS for all three: CI runs the package scripts through the nub runner: nub run test -> vitest run, nub run lint:check -> biome lint ., nub run format:check -> biome check ..
    Also: the strict and --allow-unknown outputs are identical (diff SAME), i.e. an unknown program nub produced a confident FAIL, not an "unknown".
  • evidence: .github/workflows/test.yml:28: uses: nubjs/setup-nub@47e5e7393d50f4e9544ddaf756aa277972afba2d # v0; test.yml:37: - run: nub run test;
    test.yml:52-53: - run: nub run format:check / - run: nub run lint:check; package.json:78: "test": "nub exec --node vitest run";
    package.json:72: "format:check": "nub exec --node biome check ."; package.json:74: "lint:check": "nub exec --node biome lint .".
    Validator ecosystems/javascript/__init__.py:87-110 knows npm/pnpm/yarn/bun/deno only. nub is new and rare, so this is a gap, but
    <unknown> run <script> where <script> is a package script could be treated as a script runner, or at least as unread.
  • repro: step run: nub run test with package.json {"scripts":{"test":"vitest run"}}.
  • confidence: medium
sindresorhus/got / type-checking (strict hint)
  • kind: MESSAGE
  • actual: PASS: tsc (tsconfig.json) runs + hint consider enabling strict mode: "strict": true in the compilerOptions of tsconfig.json
  • expected: the hint should allow for an extends base: got's tsconfig extends @sindresorhus/tsconfig, which is strict.
  • evidence: tsconfig.json:2: "extends": "@sindresorhus/tsconfig",. The base lives in node_modules, so it cannot be read; saying "strict is not visible (extends @sindresorhus/tsconfig)" would be accurate.
  • repro: tsconfig.json {"extends":"@tsconfig/strictest"} (the docs say @tsconfig/strictest is recognised, so a named-base allowlist exists and could grow).
  • confidence: low

Found by the regression-corpus audit (235 real repositories, one or more per ecosystem profile; corpus and expected results in corpus/). Evidence is quoted from the audited checkouts at the commits pinned in corpus/projects.toml; <checkouts>/<owner>__<repo> is such a checkout.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt

Vorherrschende Sprache
Python
Sterne
4
Forks
1
Ø Merge
10 Std. 41 Min.
Gemergte PRs (30 T.)
79

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus cpp-best-practices/project_validator

Alle Issues in cpp-best-practices/project_validator

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.