@std/expect/fn implement 'jest compatible' mock function

[anion155]

Is your feature request related to a problem? Please describe.

We do have 'Jest compatible' expect module, but it's fn implementation isn't really 'Jest compatible'. We don't have any api to support dynamic change of mock function implementation, and it seems like one of the main parts of being 'Jest compatible' in my opinion. And currently any migration of project from node to deno will require manual changes in this aspect.

Describe the solution you'd like

Provide same functionality described for Jest's mock function for @stc/expect's fn, like:

• mockImplementation() and mockImplementationOnce(), with all of the sugarcoated mockReturnValue() etc
• withImplementation().

Would be nice to return resource with [Symbol.dispose] from withImplementation() when scope callback wasn't provided.

Multiple implementation args of fn could be sugarcoated version of doing fn().mockImplementationOnce().mockImplementationOnce().

To be backward compatible and implement .mockRestore() we either could use first argument function as default implementation or provide .mockRestore() only argument instead of multiple

Also would be nice to have spyOn implementation compatible with 'Jest' version.

Describe alternatives you've considered

Come with any other better api for dynamically changing implementation

PS

I'm willing to start working on this issue my self in my free time, if that's ok

PS

Referencing my other issue about incompatibility with @std/testing/mock as I think they are closely related

Just wanted to mention issue about @std/expect's fn not being type safe here as it seems related in my opinion

[kt3k]

Seems reasonable suggestion to me. PRs are welcome!

[gmzacharydovel]

I can see if I can make a PR in a few weeks on this. I basically implemented it locally.

Looks like there is already something merged!

[mary-ext]

Surprised that the PR was rejected despite this issue being initially considered a reasonable suggestion. I'd expect most users of @std/testing/bdd to also be users of @std/expect especially if they were coming from Node.js (via Jest or Vitest), no?

Jest compatibility aside, it seems weird for two @std packages to not be interoperable given they belong in the same category.

[kt3k]

I still think this suggestion is reasonable, but I'm against #6289 which makes the maintenance of @std/testing/mock and @std/expect difficult.

We got stuck in review of #6317 because it implemented both suggestions.