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

Ouverte
#254 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
35/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
javascript, node.js, python
Domaine
testing, tooling

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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

Langage dominant
Python
Étoiles
4
Forks
1
Merge moyen
10 h 41 min
PR mergées (30 j)
79

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de cpp-best-practices/project_validator

Toutes les issues de cpp-best-practices/project_validator

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.