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

Abierto
#254 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript, node.js, python
Área
testing, tooling

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Python
Estrellas
4
Forks
1
Merge medio
10 h 41 min
PR fusionados (30 d)
79

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de cpp-best-practices/project_validator

Todos los issues de cpp-best-practices/project_validator

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.