-
Notifications
You must be signed in to change notification settings - Fork 365
stack trace #64
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
base: master
Are you sure you want to change the base?
stack trace #64
Conversation
I've come to the understanding that mot of the stack trace are irrelevant, thus this commit will remove all of it except the file and line number of the second entry in the stack trace which empirically matches the probable invocation in the test code
|
Sounds interesting, I'll take a look when I get chance. I'm a little worried about removing useful stacktrace info from test failures though. |
|
I've been trying to think about the issue a lot, and following is my understanding of how it works, please correct me if I'm wrong:
I've not tested with exception assertions, though I don't think they will be included in the stack trace, as it would imply that the stack trace are merged at some point (which doesn't make any sense). |
|
I have a slightly different approach in my self-contained branch. The inline reporter removes any lines that have 'nodeunit/' in them and also colorizes any line that belongs to the module being tested. Definitely much better signal-to-noise ratio. |
|
Instead of removing stack traces entirely can we have an option to explicitly hide them? I'm doing test driven development, and so I have a gigantic suite of tests that fail. as I implement the code more tests start to pass, but its almost unusable iteratively because the stack traces dont mean anything and take up a huge amount of space in the output. The default option would of course be to NOT hide them, I'd be super happy with the option to enable this behavior, especially at the beginning of my projects where my tests are a big mountain of fail. :) |
|
+1 @mreinstein — An option to hide stack traces would be fantastic. (nodeunit rocks, keep up the good work!) |
|
@caolan (or anyone) is this possible now? In my case the first two lines are more than enough. |
|
So, basically what @mreinstein said. |
|
+1 to what @mreinstein said, an option to turn off stack traces would be nice |
|
+1 to option @mreinstein |
Fixes error when stack trace is hidden with ```Error.stackTraceLimit = 0``` Potentially provides a fix to caolan#64
looked into the stack trace issue, and what I think is that only filename and line number of entry two in the general stack trace are relevant to show