[prefer-expect-assertions] Addition of an "ifPromisesUsed" option

I really like the prefer-expect-assertions rule, but requiring a test file to be covered in either expect.assertions(n) or expect.hasAssertions() calls when assertions aren’t nested inside promises gets a little messy.

It would be rad to be able to have an ifPromisesUsed option on the rule that when enabled, would only throw the rule if:

• The test case returns a Promise directly to Jest and
• There are no expect() calls inside of the Promises resolve or reject methods.

test('should not trigger the rule because there is explicit expectation by itself', () => {
  expect(true).toBeTruthy();
});

test('should trigger the rule because there is an expectation inside of a Promise resolver', () => {
  expect.hasAssertions(); // expect.assertions(1);
  return methodThatShouldAPromise(done => {
    expect(true).toBeTruthy();
    done();
  });
});

[G-Rath]

@erunion

re the burden of writing expect.hasAssertions boilerplate, you can use a setupFilesAfterEnv script:

/**
 * Sets up before each test an expectation for there to be assertions.
 */
beforeEach(() => expect.hasAssertions());

https://github.com/G-Rath/babel-plugin-replace-ts-export-assignment/blob/master/test/setupExpectEachTestHasAssertions.ts

https://github.com/G-Rath/babel-plugin-replace-ts-export-assignment/blob/8dfdca32c8aa428574b0cae341444fc5822f2dc6/package.json#L52-L54

Granted you can’t use that if you’re using tools other than expect, but that’ll do a lot of what you want, and you can invert it by adding expect(true).toBe(true) at the top of tests that would otherwise fail, if you wanted.

---

I think by allowing prefer-expect-assertions to be conditionally applied

I completely agree, but it’s the conditions that I’m not convinced we can accurately match enough of w/o edge cases and generally ending up attempting to do the job of a static analyzer - that’s why it’s generally best practice to always stick expect.hasAssertions in your tests if possible, regardless of complexity.

The focus of my review will be the complexity of the implementation vs what it actually covers, and what it doesn’t cover (i.e “if you import methodThatShouldAPromise then this option bails out”).

None of this is meant to discourage you from making a PR if you want to have a go; I just want to share some of my thoughts & concerns 🙂

[SimenB]

There are 2 use cases for expect.hasAssertions(); - one is the promises one you point out, and the other is conditional logic (if or throw). All these cases are better covered by https://github.com/jest-community/eslint-plugin-jest/blob/master/docs/rules/valid-expect-in-promise.md, https://github.com/jest-community/eslint-plugin-jest/blob/master/docs/rules/no-try-expect.md and https://github.com/jest-community/eslint-plugin-jest/blob/master/docs/rules/no-if.md. If you use those rules, you won’t need prefer-expect-assertions as the cases it tries to guard against should be covered.

---

That said, I’m not against the option you’re suggesting. @G-Rath thoughts?