Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

test_runner: tracking issue for code coverage stabilization

Ouverte
  • Quelque chose ne va pas ?
#63,506 1 commentaire 4 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é
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
Calme
Stack technique
javascript, nodejs
Domaine
cli, testing-qa

Piste de recherche

Commencez par la checklist de stabilisation proposée et exécutez la commande de couverture node --test --experimental-test-coverage. Le point d’entrée indiqué pour le travail restant sur les tests du cœur est test/parallel/test-runner-coverage.js ; l’achèvement dépend du triage des problèmes répertoriés et du respect des critères de sortie en plusieurs parties, plutôt que d’une seule modification isolée.

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

Description

test_runner

This issue tracks the remaining work to move node:test code coverage out of experimental.

The previous tracker, #53924 (previous stabilization tracker), was closed after narrowing the formal remaining item to replacing or aliasing --experimental-test-coverage with --test-coverage. There are still open issues and PRs that look relevant to stabilization, so it would be useful to have an umbrella issue again.

Scope

This is about test runner coverage enabled with:

node --test --experimental-test-coverage

This is not intended to track every NODE_V8_COVERAGE issue, only the ones that materially affect confidence in node:test coverage.

Proposed stabilization checklist
Likely blockers
  • Add or alias a stable --test-coverage enable flag
    • historical context: #53924 — previous stabilization tracker
  • Fix coverage correctness for isolation=none
    • issue: #60023 — coverage with isolation=none does not work correctly
    • PR: #63079
  • Fix major sourcemap correctness bugs
    • #54753 — false missing coverage for TypeScript import type
    • #55054 — sourcemap coverage can fail for remapped files
  • Confirm CLI and run() API coverage behavior are aligned for common cases
    • related: #60023 — isolation=none / API coverage mismatch
    • related PR: #63079
  • Re-enable the skipped isolation coverage test in core
    • test/parallel/test-runner-coverage.js
Strong candidates to resolve before stabilization
  • Review performance of built-in coverage
    • #55103 — built-in coverage is reported as significantly slower than existing tooling
  • Finalize default include/exclude behavior
    • issue: #63397 — default test exclusion does not match dotfiles
    • PR: #63401
  • Make reporter behavior consistent where coverage is involved
    • #60884 — dot reporter does not surface coverage output/failures clearly
    • #61586 — ignored lines and lcov branch data are inconsistent
    • PR: #63443
Likely follow-up work unless parity is required first
  • Decide whether statement coverage is required before stabilization
    • issue: #54530 — add statement coverage support
    • PR: #62340
  • Decide whether untouched files matched by include globs should report as 0%
    • #58887 — support reporting untested matched files as 0% covered
  • Decide whether excluding empty lines should be supported
    • #60996 — add an option to exclude empty lines from coverage
Open issues most directly related to test coverage
Correctness / stabilization
  • #60023 — Test runner with isolation=none does not work with coverage
  • #54753 — --experimental-test-coverage falsely reports missing coverage where TS source is import type
  • #55054 — Could not report code coverage for file in sourcemap
  • #55103 — Slow performances when running tests with --experimental-test-coverage
Reporting / exclusion / polish
  • #61586 — node:coverage ignore comments exclude DA but leave BRDA in lcov output
  • #63397 — default --test-coverage-exclude behavior does not apply to dotfiles
  • #60884 — dot reporter should print coverage failures/output
  • #58887 — report 0% coverage for untested files matched by include globs
  • #60996 — add option to exclude empty lines from coverage report
Coverage model / parity
  • #54530 — support statement coverage
Open PRs to watch
  • #63079 — test_runner: support coverage with isolation:'none' via run() API
  • #63401 — test_runner: match dotfiles in default coverage exclude
  • #62340 — test_runner: add statement coverage support
  • #63443 — test_runner: print coverage report with dot reporter
Lower-level issues worth watching

These are broader than node:test, but may still matter if they show up in test runner coverage behavior:

  • #53652 — incorrect uncovered block around some switch / case patterns
  • #41387 — inconsistent coverage information when loaders are used
  • #46378 — NODE_V8_COVERAGE behaves inconsistently with workers
  • #35212 — coverage may not be saved on SIGINT/SIGTERM
  • #44364 — NODE_V8_COVERAGE can run OOM when many scripts are compiled
  • #35783 — V8 coverage API next steps
Proposed exit criteria

Coverage can likely move out of experimental when:

  1. --test-coverage exists as the stable entry point.
  2. isolation=none coverage correctness is fixed.
  3. The major sourcemap correctness bugs are resolved.
  4. CLI and run() API behavior match for common coverage use cases.
  5. The remaining open issues are triaged into:
    • blocker for stabilization
    • follow-up semver-minor work
    • unrelated to stabilization
Note

This issue is meant to restore a single place to track stabilization work now that #53924 is closed, not to block future semver-minor improvements after stabilization.

Disclaimer: I used AI to compile this list, then edited by hand.

Langage dominant
JavaScript
Étoiles
122k
Forks
37.4k
Merge moyen
4 j 12 h
PR mergées (30 j)
296

Préparer son environnement

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 nodejs/node

Toutes les issues de nodejs/node

Issues similaires

Plus d'issues JavaScript

Recevez les nouvelles issues par e-mail

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