Harness primitive for testing expected crashes / uncaught exceptions
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 18
- Forks
- 12
- PR merge metrics
- No merged PRs in 30d
Description
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
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading test_exception/testFinalizerException.js and test_fatal to compare their subprocess expectations. Design the implementor-provided harness around the proposed expectCrash shape, including stderr matching and exception- or signal-based termination. Done means both affected tests can use the helper and still verify their expected crash outcomes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, node.js
- Domain
- testing-qa
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100