Stack traces on to.be.true/false

[pschuegr]

Apologies if this is covered somewhere but I've had no luck with finding any information.

expect(var).to.equal(true)

throws an error with a full call stack including the location of the statement, but

expect(var).to.be.true

throws an error where the call stack is all inside chai code. Is there something that can be done about this, or do I just need to use the first form?

[keithamus]

@pschuegr thanks for the issue.

This kind of looks like a dupe of #355. Could you have a look at #355 and see if this issue is the same? If it is then I recommend we close this one and work on #355, otherwise, if you could provide more information about this issue, and why it is different to #355, that'd be just swell 😄

[rileyjshaw]

@keithamus a good test case is written up here.

I'm coming up against the same problem and I'm looking for a way to suppress the stack trace on .to.equal() calls. As the link mentions, chai.config.includeStack = false doesn't help.

Any suggestions? These stack traces are making it really hard to quickly parse the reporter's output...

[rileyjshaw]

(And as far as I can tell, this is not a dupe of #355)

[keithamus]

@rileyjshaw The reduced test case in the stackoverflow link you posted helps clarify things a lot.

Having said that, I'm not entirely sure what's going on here. I welcome a PR to fix it but can't offer any insight into why its happening.

I'll mark it as hard, because I'm quite sure it's going to be hard to track down the behaviour. But a PR is welcomed! As always, PRs grant you a place on the hall of fame. If either of you are going to attempt a PR, I'd recommend announcing so here - so you don't both spend time working on it!

[kpdecker]

This should be fixed under #514.

[kpdecker]

Also seems like #425 echos a lot of the concerns here, perhaps a dupe.