Harness primitive for testing expected crashes / uncaught exceptions

Offen

#33 erstellt am 08.3.2026 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit: 5/5
Geschätzter Aufwand: Über eine Woche
Anfängerfreundlichkeit: 35/100

Issue-Typ: Feature
Klarheit: Größtenteils klar
Aktivitätsstatus: Veraltet
Tech-Stack: javascript, node.js
Bereich: testing-qa

Rechercherichtung

Beginne mit dem Lesen von test_exception/testFinalizerException.js und test_fatal, um ihre Erwartungen an Subprozesse zu vergleichen. Entwirf den vom Implementierer bereitgestellten Harness rund um die vorgeschlagene Form von expectCrash, einschließlich der stderr-Übereinstimmung und der auf einer Exception oder einem Signal basierenden Beendigung. Erledigt ist die Aufgabe, wenn beide betroffenen Tests den Helper verwenden und weiterhin ihre erwarteten Absturzergebnisse verifizieren können.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Problem

Several upstream Node.js tests verify behavior that causes the process to exit abnormally — uncaught exceptions from finalizers, fatal errors, etc. These tests use a subprocess pattern:

Spawn a child process that loads the addon and triggers the crash
Assert on the child's exit code and stderr output

The CTS currently has no equivalent harness primitive for this pattern.

Affected tests

test_exception/testFinalizerException.js (js-native-api) — finalizer throws during GC, expects process exit with "Error during Finalize" on stderr
test_fatal (node-api) — calls napi_fatal_error, expects process abort with specific message

Proposed solution

Add a harness helper that runs a code snippet in a subprocess and asserts on the outcome:

// Possible API shape:
await expectCrash({
  code: () => {
    const addon = loadAddon('test_exception');
    addon.createExternal();
    // trigger GC...
  },
  stderr: /Error during Finalize/,
  exitCode: (code) => code !== 0,
});

Each implementor would provide the subprocess execution mechanism (e.g., Node.js would use child_process.spawnSync).

Considerations

The helper needs to be implementor-provided since subprocess APIs are runtime-specific
The test code to run in the subprocess may need access to loadAddon and other CTS globals
Some crashes are signal-based (SIGABRT from napi_fatal_error) vs exception-based — the helper should handle both

Vorherrschende Sprache: C
Sterne: 18
Forks: 12
PR-Merge-Kennzahlen: Keine gemergten PRs in 30 T.

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

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

Mehr aus nodejs/node-api-cts

Drop Node.js v20 from CI matrix Offen

Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100

nodejs/node-api-cts#37 · 1 Kommentar · Erstellt am 28.3.2026
Version-derived feature flags in the node implementor misfire on runtimes that report a fictional Node version Offen

Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100

nodejs/node-api-cts#85 · Erstellt am 13.8.2026
Some tests assert V8's exact error message wording, so non-V8 runtimes fail on prose Offen

Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 48/100

nodejs/node-api-cts#84 · Erstellt am 13.8.2026
Port SharedArrayBuffer TypedArray test Offen

Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 45/100

nodejs/node-api-cts#61 · Erstellt am 15.5.2026
Setup CI for publishing of the package Offen

Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100

nodejs/node-api-cts#35 · 1 Reaktion · Erstellt am 13.3.2026

Alle Issues in nodejs/node-api-cts