Harness primitive for testing expected crashes / uncaught exceptions
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- javascript, node.js
- Ambito
- testing-qa
Direzione di ricerca
Inizia leggendo test_exception/testFinalizerException.js e test_fatal per confrontare le loro aspettative sui subprocess. Progetta l’harness fornito dall’implementatore attorno alla forma proposta di expectCrash, includendo la corrispondenza di stderr e la terminazione basata su un’eccezione o un segnale. Il lavoro è completato quando entrambi i test interessati possono usare l’helper e continuano a verificare gli esiti di crash previsti.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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 stderrtest_fatal(node-api) — callsnapi_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
loadAddonand other CTS globals - Some crashes are signal-based (SIGABRT from
napi_fatal_error) vs exception-based — the helper should handle both
- Lingua principale
- C
- Stelle
- 18
- Fork
- 12
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di nodejs/node-api-cts
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
nodejs/node-api-cts#37 · 1 commento ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
nodejs/node-api-cts#85 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
nodejs/node-api-cts#84 ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
nodejs/node-api-cts#61 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
nodejs/node-api-cts#35 · 1 reazione ·
Tutte le issue di nodejs/node-api-cts
Issue simili
-
internal.h中,漏掉了1个定义。 Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 95/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
-
Broadcast Documentation Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
kovidgoyal/kitty#10516 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 80/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
zephyrproject-rtos/zephyr#120011 ·