Harness primitive for testing expected crashes / uncaught exceptions
還沒有人認領這個 Issue。
評估
- 難度
- 5/5
- 預估耗時
- 一週以上
- 新手友好度
- 35/100
- Issue 類型
- 功能
- 描述清晰度
- 基本清楚
- 活躍度
- 停滯
- 技術堆疊
- javascript, node.js
- 領域
- testing-qa
研究方向
首先閱讀 test_exception/testFinalizerException.js 和 test_fatal，以比較它們對 subprocess 的預期。圍繞提議的 expectCrash 形式設計由實作者提供的 harness，包括 stderr 比對以及基於 exception 或 signal 的終止。當兩個受影響的測試都能使用 helper，並且仍能驗證預期的 crash 結果時，即視為完成。
由索引模型根據 Issue 內容生成。
描述
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
- 主要語言
- C
- 星號
- 18
- 分支
- 12
- PR 合併指標
- 30 天內沒有已合併 PR
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
nodejs/node-api-cts 的其他 Issue
-
難度 2/5 1-3 小時 新手友好度 68/100
nodejs/node-api-cts#37 · 1 則留言 ·
-
難度 5/5 一週以上 新手友好度 35/100
nodejs/node-api-cts#85 ·
-
難度 4/5 3-5 天 新手友好度 48/100
nodejs/node-api-cts#84 ·
-
Port SharedArrayBuffer TypedArray test可能已有人在做 @hexbinoct 於 72 天前認領。 未關閉
難度 3/5 1-2 天 新手友好度 45/100
nodejs/node-api-cts#61 ·
-
難度 4/5 3-5 天 新手友好度 35/100
nodejs/node-api-cts#35 · 1 個 reaction ·
查看 nodejs/node-api-cts 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 84/100
ARM-software/CMSIS-DSP#354 ·
-
good first issue help wanted
難度 2/5 1-3 小時 新手友好度 77/100
維護者通常 1 天內回覆
-
documentation good first issue help wanted
難度 2/5 1-3 小時 新手友好度 76/100
ai-quokka-wannabe/link#40 ·
-
Add `pdfcpu` to the pantry可能已有人在做 關聯的 PR 仍在進行中或已合併。 未關閉
難度 2/5 1-3 小時 新手友好度 72/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100
eunomia-bpf/agentsight#240 ·
維護者通常 1 天內回覆