High Impact Suggestions for the Team

Offen
  • Stimmt etwas nicht?
#21 6 Kommentare 9 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

@vassudanagunta arbeitet bereits daran.

Seit 07.3.2026.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
18/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Tech-Stack
javascript, node.js
Bereich
developer-experience, testing-qa, tooling

Rechercherichtung

Start by separating the proposed work into the linked coverage, npm scripts, console output, and module mocking issues, then review the referenced Console implementation and pull request. The issue has no single entry point or acceptance criterion; each proposal would need its own scope, design, and definition of done.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

test_runner-agenda

Hi Test Runner Team,

I realize that everyone here is a volunteer and contributes whatever they want (or doesn't even contribute at all). There are some issues that I think may be flying under your radar that I think could have a big impact on the test runner experience:

  • Finish/stabilize code coverage. I've seen this in use a fair amount in the wild, but people always point out that it is still experimental. I think it's worth evaluating the accuracy and considering stabilizing it. The performance would also be good to look at, but should not be considered a blocker since it can be improved without impacting users. Coverage also does not support statement level coverage, but this should not be a blocker because:
    • This is an artifact of V8's coverage output. Outside of changing V8, getting statement level coverage would require an additional parsing pass over all of the source code to map statements to positions in files. This would almost certainly be bad for performance.
    • I believe C8 also does not support statement coverage for V8 output. My understanding is that line coverage is reported as statement coverage because it's good enough.
    • It can always be added in a semver minor change if someone comes up with a good solution.
  • Combining test runner flags with npm scripts (https://github.com/nodejs/node/issues/51384) - There are some possible solutions described in that thread. Right now, it's possible to work around this with NODE_OPTIONS, but it's not really a nice solution. That issue appears to be a blocker to jsdom adopting the test runner for example. This would be a massive DX improvement.
  • Properly associating console.log() output with its test in the reported output (https://github.com/nodejs/node/issues/53103) - One way to solve this could be to add code to Console, similar to what diagnostic channels do. Then, that code could integrate with the test runner's reporter functionality. This would be a massive DX improvement.
  • Stabilize module mocking. If https://github.com/nodejs/node/pull/61767 lands, I think it would make sense to leverage that first. I wanted to do something similar when I originally wrote the mocking code, but I anticipated there being FAR more pushback on breaking spec compliance then there has been in #61767. For ESM in particular, #61767 has the potential to greatly improve the DX of module mocking.

Some other nice to have changes would be:

  • Migrate the test runner off of async_hooks. Now that AsyncContextFrame, it may be possible to achieve the same functionality, and I believe the project would like to get rid of async_hooks. Currently, async_hooks are only used to map asynchronous activity back to the test that initiated it. I haven't investigated what it would take to make this change in much detail.
  • Give the spec reporter a new paint job. As long as you don't change the programmatic behavior of the reporter, we are free to change the actual output (text, colors, etc.) of the reporters without regard for semver. This has the potential to be a big DX improvement.
Vorherrschende Sprache
Keine Sprachdaten
Sterne
3
Forks
4
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

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 nodejs/test-runner

Alle Issues in nodejs/test-runner

Ähnliche Issues

Weitere Issues zu DevTools

Neue Issues direkt in Ihr Postfach

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