Open LPGhatguy opened 4 years ago
Do you have an example of where this would be useful?
When testing code that involves passing a closure to another function, it'd be useful to ensure an expectation failure isn't caught by pcall
.
Imagine we're writing a test like this:
it("should fail if yadda yadda yadda", function()
local result = runAThing(function(x)
expect(x).to.equal(1)
end)
expect(result).to.equal("success")
end)
It's possible that a change to runAThing
would start using pcall
on the passed function, perhaps incorrectly, swallowing a failing test assertion in the process.
One case where this comes up in practice is in promises, which explicitly turn errors into promise rejections, which are easy to accidentally ignore. You can see the large number of promise rejection warnings in the lua-apps test suite as an example of this. 😢
I'm a bit averse to making expect more magical, but I can see this being useful, and not any downsides at present.
It would be nice to have unhandled rejections show up in the reporter somehow, perhaps as a failed afterAll hook. In jest/node I have had this working by waiting for all promises to resolve before exiting the process (with a timeout). Might be more tricky for us though.
I think that'd be doable. We'd need to track which test each promise came from to be useful, which would require some integration into the promise library, but would also add a lot of value.
If an expectation is caught by
pcall
orxpcall
it should still fail the containing test. This can help guarantee that if code runs, it is able to fail a test!There may be some compatibility concerns for code using
expect
in... unexpected ways 😎