You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I realised this while doing #1191 and gosh is it a tough one: prefer-expect-assertions is currently checking if a function call is expect.hasAssertions or expect.assertions using non-scoped means:
However, there's a very subtle problem which is that the rule works by checking the first statement in the body of the function being passed to test or it - this is a problem because context.getScope() is stateful, so calling parseJestFnCall will have it use the scope of the test/it method rather than the scope of the function body the expression is in.
Because we're checking the first expression it's harder to exploit, but e.g. this won't fail:
it("returns numbers that are greater than four", function(expect) {
expect.assertions(2);
for(let thing in things) {
expect(number).toBeGreaterThan(4);
}
});
I think we should be able to solve this by switching to preemptively checking every first statement in a test/it function body and then check if is anything that means we should not report (i.e. loops) - it'll add a bit more complexity but I don't think we can resolve this bug otherwise 🤷
When I get a chance I'll probably land the initial fix first since that is still part of this and will resolve the main bug.
The text was updated successfully, but these errors were encountered:
I realised this while doing #1191 and gosh is it a tough one:
prefer-expect-assertions
is currently checking if a function call isexpect.hasAssertions
orexpect.assertions
using non-scoped means:This can be fixed with this:
However, there's a very subtle problem which is that the rule works by checking the first statement in the body of the function being passed to
test
orit
- this is a problem becausecontext.getScope()
is stateful, so callingparseJestFnCall
will have it use the scope of thetest
/it
method rather than the scope of the function body the expression is in.Because we're checking the first expression it's harder to exploit, but e.g. this won't fail:
I think we should be able to solve this by switching to preemptively checking every first statement in a
test
/it
function body and then check if is anything that means we should not report (i.e. loops) - it'll add a bit more complexity but I don't think we can resolve this bug otherwise 🤷When I get a chance I'll probably land the initial fix first since that is still part of this and will resolve the main bug.
The text was updated successfully, but these errors were encountered: