The problem here is that the rule is actually right for some cases - expect will actually call a passed function under certain circumstances.
For example expect(clazz.method).toThrow() will call the passed function with an incorrect this context.

Which is the inherent danger of an allowlist like this - it's contextless and can easily cause footguns.
IMO it's better to have a tighter API with some false-positives which a user can assess and disable as appropriate, than a looser API with some false-negatives that are invisible and then cause runtime errors. These are terrible erode user trust in the linting ecosystem as a whole, not just one lint rule ("if this rule missed this case, what other rules are missing cases...")

Don't get me wrong - I 100% understand that it's clunky and cumbersome to manually disable the rule around the place, but it's just a really hard problem to solve, and is an inherent problem with the dynamic nature of JS.

Do we need a solution? Yes.
As much as I prefer false-positives, they also erode user's trust, but in a different way ("I know this rule over-reports, so I can just ignore it.").

Do I have a good solution? Nope.
allowlists are not good because whilst we can say "hey make sure you limit the scope of your allowlist to ensure you don't cause false-negatives", there's no way to enforce that, which is a huge foot-gun and an API design smell. On the one hand - sure let users shoot themselves, they'll learn. But on the other hand, they'll raise an issue here when they encounter it (and usually with a barely filled out issue).

Perhaps a better solution is to fork this rule into something like eslint-plugin-jest, and teach it how to deeply analyse expect.
I.e. it could be taught that expect(clazz.method).toBeTruthy() is safe, but expect(clazz.method).toThrow() is unsafe.
Then a user could enable that version in test files (limiting the scope of it's logic), and enable our version everywhere else.

Unsure... Just a random thought.

Perhaps a better solution is to fork this rule into something like eslint-plugin-jest,

I had the exact same though minutes after hitting "submit" 😅

Do you have any documentation or examples on how we could easily hook into the type info for our rules over at eslint-plugin-jest? I thought I remembered seeing some at some point but can't find it now (it might have been on a PR).

For that idea - it could actually be as simple as forking the rule and adding some additional checks using ESTree AST to look for jest patterns and then just prevent the unbound-method logic from running.

eg:

if (isExpectToThrow(node) || isExpectNotToThrow(node)) {
  checkUnboundMethod();
} else {
  return;
}

So I've started forking the rule, but having trouble forking the tests - would you mind having a look?

Initially I got Parsers provided as strings to RuleTester must be absolute paths, which I resolved by using require.resolve to pass the parser property.

That then gave me The file does not match your project config: estree.ts which I resolved by adding files: ["estree.ts"] to fixtures/tsconfig.json.

Finally, I'm now having a couple of tests fail 😬

So far the majority of our setup seems to be the same, except for Leara. It could be because of version differences, but I'd have thought that'd make for some pretty flakey tests if patch difference versions in packages like @types/node had this much effect.

Initially I got Parsers provided as strings to RuleTester must be absolute paths, which I resolved by using require.resolve to pass the parser property.

That then gave me The file does not match your project config: estree.ts which I resolved by adding files: ["estree.ts"] to fixtures/tsconfig.json.

You want to use ESLintUtils.RuleTester instead of TSESLint.RuleTester.
The former includes utils and config to help do tests.
The later is just a typed version of the class and nothing more.

They're separate so that people don't get our stuff forced on them.

Finally, I'm now having a couple of tests fail 😬

I would have thought that if you just fork the rule and make no changes, it should all "just work".

I would have thought that if you just fork the rule and make no changes, it should all "just work".

As would I, but sadly no dice so far - I'll look into using ESLintUtils.RuleTester and see if that helps.

(Slightly surprised my PR actually closed this issue - I'm guessing probably because I was the author of both)

@bradzacher I've merged the new rule in eslint-plugin-jest - once we've lived with it for a bit to weed out any bugs, I'll make a PR updating unbound-methods docs to link the two together :)