-
-
Notifications
You must be signed in to change notification settings - Fork 6.6k
Closed as not planned
Closed as not planned
Copy link
Labels
Description
🚀 Feature Proposal
expect.hasAssertions()
should only report an issue when the test is passing.
Motivation
When the JavaScript code fails due to an error, it causes double output with Jest. For example, the following test:
it('fails the test', () => {
throw new Error('woops!');
expect(true).toBe(true);
});
Produces this output:
● .CONTENT_NUMBER_REGEX › fails the test
woops!
5 |
6 | fit('fails the test', () => {
> 7 | throw new Error('woops!');
| ^
8 |
9 | expect(true).toBe(true);
10 | });
at Object.<anonymous> (spec/javascript/constants_spec.ts:7:11)
at runMicrotasks (<anonymous>)
● .CONTENT_NUMBER_REGEX › fails the test
expect.hasAssertions()
Expected at least one assertion to be called but received none.
44 |
45 | beforeEach(() => {
> 46 | expect.hasAssertions();
| ^
47 | });
48 |
49 | afterEach(() => {
at Object.<anonymous> (spec/javascript/test_helper.ts:46:10)
at runMicrotasks (<anonymous>)
If you're running your tests in a tiny VSCode pane, all you see is the hasAssertions()
error which is a red herring. You need to scroll up to see the real error.
Example
Instead of displaying the hasAssertions
error, when the test is already failing we should only see the relevant failure:
● .CONTENT_NUMBER_REGEX › fails the test
woops!
5 |
6 | fit('fails the test', () => {
> 7 | throw new Error('woops!');
| ^
8 |
9 | expect(true).toBe(true);
10 | });
at Object.<anonymous> (spec/javascript/constants_spec.ts:7:11)
at runMicrotasks (<anonymous>)
Pitch
Because the hasAssertions()
option is part of the Jest core platform, it seems like this makes sense to address there as well.