[jest-circus] Omit expect.hasAssertions() errors if a test already has errors

[danbeam]

Addresses #14084

Summary

When using expect.hasAssertions(), if an it() block throws early, you see both an error for the thrown thing and an error about not having called expect(). While this is technically correct, it's a bit spammy, IMO. The test is already gonna fail.

Example

Test:

beforeEach(() => expect.hasAssertions());

it('is correct', () => {
  expect(1).toBe(1);
});

it('is wrong', () => {});

it('is spammy', () => {
  throw new Error('throwing'); // imagine this may vary on whether it throws in reality
  expect(1).toBe(1);
});

Before:

 FAIL  frontend/example/__tests__/example.test.ts
  ✓ is correct (4 ms)
  ✕ is wrong (1 ms)
  ✕ is spammy (2 ms)

  ● is wrong

    expect.hasAssertions()

    Expected at least one assertion to be called but received none.

    > 1 | beforeEach(() => expect.hasAssertions());
        |                         ^
      2 |
      3 | it('is correct', () => {
      4 |   expect(1).toBe(1);

      at Object.hasAssertions (frontend/example/__tests__/example.test.ts:1:25)

  ● is spammy

    throwing

       8 |
       9 | it('is spammy', () => {
    > 10 |   throw new Error('throwing'); // imagine this may vary on whether it throws in reality
         |         ^
      11 |   expect(1).toBe(1);
      12 | });
      13 |

      at Object.<anonymous> (frontend/example/__tests__/example.test.ts:10:9)

  ● is spammy

    expect.hasAssertions()

    Expected at least one assertion to be called but received none.

    > 1 | beforeEach(() => expect.hasAssertions());
        |                         ^
      2 |
      3 | it('is correct', () => {
      4 |   expect(1).toBe(1);

      at Object.hasAssertions (frontend/example/__tests__/example.test.ts:1:25)

Test Suites: 1 failed, 1 total
Tests:       2 failed, 1 passed, 3 total
Snapshots:   0 total
Time:        1.392 s
Ran all test suites matching /frontend\/example\/__tests__\/example.test.ts/i.

After:

 FAIL  frontend/example/__tests__/example.test.ts
  ✓ is correct (4 ms)
  ✕ is wrong (2 ms)
  ✕ is spammy (2 ms)

  ● is wrong

    expect.hasAssertions()

    Expected at least one assertion to be called but received none.

    > 1 | beforeEach(() => expect.hasAssertions());
        |                         ^
      2 |
      3 | it('is correct', () => {
      4 |   expect(1).toBe(1);

      at Object.hasAssertions (frontend/example/__tests__/example.test.ts:1:25)

  ● is spammy

    throwing

       8 |
       9 | it('is spammy', () => {
    > 10 |   throw new Error('throwing'); // imagine this may vary on whether it throws in reality
         |         ^
      11 |   expect(1).toBe(1);
      12 | });
      13 |

      at Object.<anonymous> (frontend/example/__tests__/example.test.ts:10:9)

Test Suites: 1 failed, 1 total
Tests:       2 failed, 1 passed, 3 total
Snapshots:   0 total
Time:        1.4 s, estimated 2 s
Ran all test suites matching /frontend\/example\/__tests__\/example.test.ts/i.

Test plan

I didn't see much that's directly exercising this code at the moment so I created a new test.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: danbeam / name: Dan Beam (307cfe1)

[netlify]

✅ Deploy Preview for jestjs ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	307cfe1
🔍 Latest deploy log	https://app.netlify.com/sites/jestjs/deploys/65b2cf829590e50008b629ef
😎 Deploy Preview	https://deploy-preview-14866--jestjs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[lencioni]

While this is technically correct, it's a bit spammy, IMO. The test is already gonna fail.

To extrapolate this a bit further, having this extra failure being reported is a distraction/red herring that can hide the error that actually needs to be addressed and wastes developer time. I'm in favor of making this change.

One alternative that may be worth considering is exposing the pass/fail status of the test from expect.getState() #5292

If that were available, then this issue could be avoided by changing the beforeEach in this PR's example to an afterEach like this (depending on the implementation of #5292):

afterEach(() => {
  if (expect.getState().status !== 'failed') {
    expect.hasAssertions();
  }
});

[SimenB]

yeah, this makes a lot of sense. Thanks!

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.