It should be an error to `@patch` a function that isn't `@mock`ed. Currently it is silently ignored.

[NHDaly]

I was recently debugging a test that accidentally patched the wrong function. (The mocked function was the patched function's callee.)

Instead of getting an error, as I'd expect, to protect the programmer from the mistake the test silently passed, even though actually the test would have been broken if the patch was on the correct function. This is quite bad, and should be fixed.

Here is a simple example. I would expect this to throw an error on the @patch call, rather than proceeding:

julia> foo() = 10
foo (generic function with 1 method)

julia> apply(@patch foo() = 3) do
           @show foo()
       end
foo() = 10
10

Thank you!

[NHDaly]

Oh, hang on. I might be wrong about this. I've forgotten how this package works. You don't @mock the function definition, you mock its callsites... So there's nothing wrong with this example since the pattern would be bar() = @mock foo(), and then you'd call bar in the test.... 🤔

This is still a bit difficult to use correctly. It was still the case that the patch was on a function that wasn't being mocked, and there was no way for the framework to notify us of that.

[rofinn]

There are debug logs you can enable to help with that, but agreed, this never seemed entirely ergonomic.

[omus]

The choice for using @mock on the call sites instead of the method definition was done as you may want to patch a call for a method for which you don't control. Long ago I looked into using tools like Cassette.jl for adding in the @mock hooks without requiring the macro (#53) which would be more ergonomic but took a massive performance hit.

It should be possible to additionally add the mocking hooks on method definitions allow an alternative approach. However, one gotcha I see is being how to be able to call the unpatched method from within a patch.