expect-expect & no-standalone-expect when using expect in afterEach

[k-funk]

Example Code

Sometimes I group my enzyme snapshot tests like this to avoid writing expect(shallowToJson(wrapper)).toMatchSnapshot() repeatedly:

import React from 'react';
import { shallow } from 'enzyme';
import shallowToJson from 'enzyme-to-json';

import Component1 from './index';


describe('outputs the expected tree when', () => {
  let wrapper;
  
  test('prop1 is foo', () => {
    wrapper = shallow((
      <Component1 prop1="foo" />
    ));
  });
  
  test('prop1 is bar', () => {
    wrapper = shallow((
      <Component1 prop1="bar" />
    ));
  });

  afterEach(() => {
    expect(shallowToJson(wrapper)).toMatchSnapshot();
  });
});

The tests are often times more complex than ^ with which props are being passed.

---

Problem

There are two eslint-plugin-jest rules that I'd like to use, expect-expect and no-standalone-expect, but they are incompatible with the pattern above.

• expect-expect: my tests don't have an expect (but afterEach does)
• no-standalone-expect: my expect is not inside a test (but is in an afterEach of a describe that contains tests)

---

Proposed solution

Could the two rules be modified to allow the above use case?

no-standalone-expect could have options for which blocks are valid. Default could remain test and it. Optional: "jest/no-standalone-expect": ["error", allowedBlocks: ['test', 'it', 'afterEach']]

[gndelia]

I was about to open a similar ticket, but I found yours. I am having a different scenario, but similar issue.

We added this library to for our tests https://www.npmjs.com/package/jest-theories, so our tests now run inside theoretically functions. Though we know about using jest.each, this tiny addition fit our team, given most of them have a C# background and use a very similar library

Because of this we had to disable jest/no-standalone-expect in the files were we started to use this library, because now expects run under theoretically - it would be great to be able to customize the blocks, as you suggested

[rdsedmundo]

+1 for the suggestion of adding the allowedBlocks, that would allow compatibility with jest-in-case.

[mfogel]

Was this implemented by #585? To allow expect in the setup and teardown functions, I have in my eslint config:

      "jest/no-standalone-expect": [
        "error",
        {
          "additionalTestBlockFunctions": [
            "beforeAll",
            "beforeEach",
            "afterEach",
            "afterAll"
          ]
        }
      ]

And then jest/expect-expect could be disabled to get the full affect the OP is looking for.

Safe to close?

[k-funk]

no-standalone-expect works great. Thanks!

But turning off jest/expect-expect completely also seems wrong. It is valuable to know if if there are no expects in afterEach/afterAll, nor a test

[G-Rath]

So I'm about to make a PR for adding additionalTestBlockFunctions to expect-expect as I think that has a valid use-case (i.e jest-theories) however @k-funk I'm somewhat opposed to having allowedBlocks as I feel this is going against what test & it are meant to be used for.

Personally I'd recommend looking to alias the methods instead, which which would solve this problem:

import React from 'react';
import { shallow } from 'enzyme';
import shallowToJson from 'enzyme-to-json';

import Component1 from './index';

const showcase = test; // other good names could be "setup", "define", "propose", etc

describe('outputs the expected tree when', () => {
  let wrapper;
  
  showcase('when prop1 is foo', () => {
    wrapper = shallow((
      <Component1 prop1="foo" />
    ));
  });
  
  showcase('when prop1 is bar', () => {
    wrapper = shallow((
      <Component1 prop1="bar" />
    ));
  });

  afterEach(() => {
    expect(shallowToJson(wrapper)).toMatchSnapshot();
  });
});

You should be able to set this up in a setup file so you wouldn't need to do it in every test.

(In saying that, we do want to support being able to define which methods are actually considered test methods as a config that's used by each rule, which thinking about it should probably be accompanied by a rule-level override + some consistent properties; so you will be able to do this eventually)

[G-Rath]

Resolved via #1129