-
-
Notifications
You must be signed in to change notification settings - Fork 697
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
Question regarding stack trace. #878
Comments
Chai's core is pretty solid - we code pretty defensively, but we don't have much influence over plugins, which can cause genuine errors within the assertion. Sometimes it is actually useful to read the code of the assertion that failed. I've certainly - more than a handful of times - read the code of the assertion that's throwing to check what is going wrong. Your utility looks super useful - and I've been thinking a lot about doing the exact same thing somehow in chai or perhaps up the stack in the test runner (like mocha). Please let us know when you've finished developing this! I'd love to take a look ❤️ |
Hmmm ok. So if I want to display the code frame at the point in which the assert was called (which I believe is more useful as I write tests), I am going to have to sniff for the chai I see it as the only solution, but it arrises the following issues:
Ideally I was hoping it could just work out of the box. Ex: Am I overlooking any possible solutions? Quick example of what the output looks like after quickly hacking in the |
@jaridmargolin I'm gonna take a look at this stuff this weekend. Note that there's a related issue in chai@4.0.0-canary.1 with the proxy-related frames showing up in the stack trace. |
@meeber 👍 Additionally, the more I think about this... maybe extracting out various addons isn't the end of the world. As long as the plugins are automatically loaded from This would allow for third party addons to be tailored towards whatever tools the consumer decides to use. For example, in the above mocha run, an addon could enable filtering out mocha entries in the stack trace (which again, I feel like 99.99% of the time is not necessary to display). |
Let's compare the stack traces between the different interfaces in Chai v4.0. Tests: it("assert", function () {
assert.isTrue(false);
});
it("expect", function () {
expect(false).to.be.true;
});
it("should", function () {
false.should.be.true;
}); Results:
The reason the My initial impression is that we should implement such a change; most of the time, the implementation frames aren't needed, and in the rare occasion that they are, they can be enabled using the Regarding the extra proxy frames in v4.0: These are easily removed by using the proxy getter as the first frame to remove instead of the object getter. I'll submit a PR for that in a day or two. |
Oh... Great! Thanks for looking into @meeber |
Currently chai implements some magic to hide internal stack traces on
AssertionError
's. Cool stuffs btw! I am however curious why the stack includes the actual assert implementation. Does it provide additional value to the user? There may be a very obvious reason, so please bare with any possible stupidity on my part :)Example:
99.99% of the time I am looking for:
In fact, in the few years I have been using chai, I not once followed a stacktrace to view the internal assert implementation.
Just as a little background, I'm working on a small util to pretty up stack traces for a testing tool I am developing:
The text was updated successfully, but these errors were encountered: