[no-standalone-expect] allow specifying what to consider a test block via an option

[G-Rath]

This is pretty much the equivalent of expect-expect's assertFunctionNames option: We should support consuming an array of arbitrary strings of which we should consider as "test blocks".

This would allow extensions to work nicely with this rule, such as jest-each.

It's probably best to just to make the default value the current blocks we test for, in the same way expect-expect has expect as it's default.

[yairkukielka]

If you're using jest-each and jest >=22, see this answer.

[Lusito]

I'd like to see this too, since I've extended the describe.each and it.each functions with some additional properties.

[zwang180]

Just run into a situation where this would be really helpful:

In the project that I'm working on, we are leveraging Next.js's environment variables feature to control the app's behavior, and we are trying to create unit tests coverage for those behaviors. Essentially we are doing something like:

// test-utils.js
export const testIfA = process.env.MY_VAR === 'A' ? test : test.skip;
export const testIfB = process.env.MY_VAR === 'B' ? test : test.skip;
// others...

// myCode.test.js
import { testIfA, testIfB } from './test-utils.js';

describe('My tests', () => {
  testIfA('Only when A', () => {
    // test A behavior
  });

  testIfB('Only when B', () => {
    // test B behavior
  });
}); 

And no-standalone-expect will error out for any expect usage in both the testIfA and the testIfB block since it cannot recognize that it is a test block. Hence it will be really helpful if we could whitelist our helper functions to be considered as test blocks.

[github-actions]

🎉 This issue has been resolved in version 23.15.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀