[expect-expect] support chained function names

[erunion]

[see #418 for previous discussion]

Currently expect/expect doesn't recognize supertest or sinon assertions. For example:

const spy = sinon.spy()
it('should work as expected', async () => {
  // test code here

  sinon.assert.calledOnce(spy);
});

Adding sinon (or calledOnce) into the assertFunctionNames configuration block doesn't get recognized, so it would be cool to:

• Be able to supply full, chained, functions to assertFunctionNames like sinon.assert.calledOnce.
• It would also be neat to be able to do the same but with a glob-style syntax. Something to the effect of sinon.assert.* or for supertest cases, request.*.expect.

[erunion]

Turns out adding sinon.assert.calledOnce into assertFunctionNames works, and has tests, already! It would still be nice to be able to do glob syntax since right now the only way to kind of get supertest matching is to add your common supertest constant name (likely request) as a function name, and that's way too general. Not to mention having to duplicate every sinon assertion.

[G-Rath]

Yeah I was pretty sure I'd already implemented that for this exact reason 😄

While I understand why globbing sounds useful, I feel like it could be an easy footgun since it could result in non-assertion method being counted by mistake.

Plus as soon as you have "globbing" people generally expect it to work in a similar way to how it does everywhere else, so we'd have to add a new dependency for something like micromatch or globby.

None of these are a hard no, but I'll have it on the backburner for now, and have a think.

[jrnail23]

@erunion, I just stopped by to create an feature request for this exact issue (supertest's expect), so you already beat me to it.

@G-Rath, I tend to agree with your concerns about globbing, but would it be possible to (optionally) detect usages of a method by name, rather than only standalone functions?

[erunion]

Instead of globbing, I've been playing around with a PR that'd support regex matching instead, but haven't made much progress so far due to my lack of ESLint parsing internals.

[folke]

This issue can be closed since 295ca9a implements this