-
Notifications
You must be signed in to change notification settings - Fork 30.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test runner naively rethrows non-testing error without preserving stack trace #44611
Comments
why isn't this expected? |
When the code that is being tested crashes, either the code is broken or the test is broken (or both). You want to then be able to debug this with full information. Currently the test runner catches non-testing errors and strips them of their stack trace. This makes debugging unnecessarily hard. So in other words: I expect a test runner to give me (at least) the same information about what’s going wrong with my code as I am given when I run my code directly (without a test runner). |
I haven't been able to reproduce the issue, could you provide some example code? This code appears to retain the stack trace in the test runner output: import test from 'node:test';
function someOtherFunction() {
throw new Error('foo');
}
function someFunction() {
someOtherFunction();
}
test('foo', async () => {
someFunction();
});
|
import test from 'node:test';
function someOtherFunction() {
throw new Error('foo');
}
test('foo', async () => {
await new Promise(resolve => {
setTimeout(() => {
someOtherFunction();
resolve();
});
});
});
|
Thanks, I can reproduce this. Because this does not seem to happen when removing the test runner boilerplate, I am assuming it is indeed a bug in the test runner. |
PR-URL: nodejs#44614 Fixes: nodejs#44611 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
PR-URL: nodejs#44614 Backport-PR-URL: nodejs#44873 Fixes: nodejs#44611 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
PR-URL: nodejs#44614 Backport-PR-URL: nodejs#44873 Fixes: nodejs#44611 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
PR-URL: nodejs#44614 Backport-PR-URL: nodejs#44873 Fixes: nodejs#44611 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
PR-URL: nodejs/node#44614 Fixes: nodejs/node#44611 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
PR-URL: nodejs/node#44614 Fixes: nodejs/node#44611 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
PR-URL: nodejs/node#44614 Fixes: nodejs/node#44611 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> (cherry picked from commit cb7e0c59df10a42cd6930ca7f99d3acee1ce7627)
PR-URL: nodejs/node#44614 Fixes: nodejs/node#44611 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> (cherry picked from commit cb7e0c59df10a42cd6930ca7f99d3acee1ce7627)
PR-URL: nodejs/node#44614 Fixes: nodejs/node#44611 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> (cherry picked from commit cb7e0c59df10a42cd6930ca7f99d3acee1ce7627)
PR-URL: nodejs/node#44614 Fixes: nodejs/node#44611 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> (cherry picked from commit cb7e0c59df10a42cd6930ca7f99d3acee1ce7627)
Version
v18.8.0
Platform
Darwin Tims-MacBook-Pro.local 21.6.0 Darwin Kernel Version 21.6.0: Wed Aug 10 14:28:23 PDT 2022; root:xnu-8020.141.5~2/RELEASE_ARM64_T6000 arm64
Subsystem
test runner
What steps will reproduce the bug?
The following line of code in the test runner harness rethrows an error if it is not coming from a test:
node/lib/internal/test_runner/harness.js
Line 35 in 59527de
In the process
err.stack
is lost, while this is crucial information for understanding what went wrong.How often does it reproduce? Is there a required condition?
I am not familiar enough with the test runner’s architecture, but I think this is relevant in scenarios where the code that throws the original error runs in a timer such as
setInterval
.What is the expected behavior?
The test runner’s stdout includes the original error’s stack trace.
What do you see instead?
The test runner only displays the stack trace of the rethrown error, which isn’t very helpful.
Additional information
No response
The text was updated successfully, but these errors were encountered: