unexpected
unexpected copied to clipboard
unexpectedjs
Attach a stack trace to the it() block promise error generated if pre…
…sent.
No idea why this never opened - but this is the change so far. If previously asked for any suggestions about the best way of testing this :)
Coverage decreased (-0.03%) to 97.902% when pulling 329caa623e49dfca8ca69f4821b5b6626f8d5f7c on alexjeffburke:add-trace-on-promise-notify into 45d7e014dae720881539bee15538a550c917c980 on unexpectedjs:master.
Coverage decreased (-0.03%) to 97.902% when pulling 005f2efe3426acd54712bad3d79cfd1e509287fb on alexjeffburke:add-trace-on-promise-notify into 45d7e014dae720881539bee15538a550c917c980 on unexpectedjs:master.
@alexjeffburke, are you still working on this? Did my feedback make any sense? :)
@papandreou it completely did and thought I'd mention I've brought this back to life :)
Working on a small patch the records any pending promises in an array - but first, actually had a little problem with _trace. Struggled with the env incarnation required to get the trace - I seemed to end up with. promise that didn't have a top level _trace but one down the stack did. What are the latest env args - I was trying UNEXPECTED_FULL_TRACE and BLUEBIRD_DEBUG.
Oh and re stack trimming, you'll have to point me at where/how that's done as I'm not familiar with it.
Coverage decreased (-0.03%) to 97.911% when pulling 9931c3c83fc75d3695098e28f27dffa128b39747 on alexjeffburke:add-trace-on-promise-notify into fc1ce8aef4d7a560c1ac4140448d80b012fa945e on unexpectedjs:master.
What are the latest env args
UNEXPECTED_FULL_TRACE should be the only one relevant to users. It implies BLUEBIRD_DEBUG so you get the full async traces based on Bluebird's _trace captured at promise creation time.
What changed with #300 was that even when you don't specify UNEXPECTED_FULL_TRACE, Unexpected will attach a stack trace to all promises that it finds cannot be "oathbroken", ie. decidable synchronously, after evaluating an assertion. (Other promises that float around won't get _trace, though, so maybe that's what you ran into). In this case the _trace won't be completely correct, but the inaccuracy is cancelled out by the stack trimming code, which removes the Unexpected-internal stack frames anyway, so the end result is the same as with BLUEBIRD_DEBUG turned on, only cheaper :)
In your case I think UNEXPECTED_FULL_TRACE (or at least BLUEBIRD_DEBUG) is a necessity to be able to get to the bottom of this kind of error, though, as you really want to have _trace available on every promise, not just the ones that Unexpected decides to attach _trace to.