Cannot configure `eslint-plugin-jest`'s `expect-expect` and `no-standalone-expect` rules to recognize `test.prop`

[TomerAberbach]

🐛 Bug Report

I used to configure eslint-plugin-jest's expect-expect rule like so:

{
  "jest/expect-expect": [
    "error",
    {
      "assertFunctionNames": ["expect"],
      "additionalTestBlockFunctions": ["testProp"]
    }
  ]
}

And it would work for fast-check's testProp function. However, now that test.prop is preferred and testProp is deprecated, I tried switching to:

{
  "jest/expect-expect": [
    "error",
    {
      "assertFunctionNames": ["expect"],
-      "additionalTestBlockFunctions": ["testProp"]
+      "additionalTestBlockFunctions": ["test.prop"]
    }
  ]
}

But unfortunately this doesn't work. Probably because with test.prop the test function is not actually contained within the parentheses of test.prop(...) and is instead contained within the parentheses of an anonymous function returned by test.prop.

I understand that test.prop is attempting to match test.each so maybe what we need to do is make a feature request for eslint-plugin-jest to support configuring test.each-like functions.

What do you think?

[TomerAberbach]

Realized that no-standalone-expect has the same issue. It has the same configuration options

[dubzzz]

Indeed probably worth proposing that as an improvement of the eslint rules. 🤔

[dubzzz]

By the way, while test.prop seems more natural with Jest runner, I may have something à-la testProp (probably called fuzz) for vitest. The maintainers of vitest recommended to create a new name if I want to extend their runner.

[TomerAberbach]

Indeed probably worth proposing that as an improvement of the eslint rules. 🤔

Did you want me to file the issue or did you want to do it? I'm good either way

[dubzzz]

I prefer if you open it. You have more context on what you tried