Right now this also breaks the ability to mock functions that are local variables,
to the function where the @patch is declared.
This should never matter in the wild,
since you will never do that.

I think it is actually fixable, and I am just not fixing Binding's right.
But I also think it doesn't matter

Related to this is the inability to mock functions that are declared as local variables.
But the causes is different.
In that case it is because it is no-longer possible to mock things by name.

I can think of a way to mock things by name, but it involves overdubbing every single call.
so not good.

Other thing that is broken is the ability mock some calls but not others.
@mock(foo(x)) != foo(x)
Since mock is now a no-op.

Again, I don't think this should ever occur in the wild.

This is fixible but from a unit-testing perspective I don't think it is useful

FYI @mock in commit messages pings this guy. I typically say at-mock in commit messages to avoid pings. (I asked GitHub a long time ago to remove that "feature" but nothing has come of that so far.)

Other thing that is broken is the ability mock some calls but not others.
@mock(foo(x)) != foo(x)
Since mock is now a no-op.

Again, I don't think this should ever occur in the wild.

This is fixible but from a unit-testing perspective I don't think it is useful

Codecov Report

Merging #60 into master will decrease coverage by 6.39%.
The diff coverage is 90.32%.

@@            Coverage Diff            @@
##           master      #60     +/-   ##
=========================================
- Coverage   93.23%   86.84%   -6.4%     
=========================================
  Files           4        6      +2     
  Lines         281      228     -53     
=========================================
- Hits          262      198     -64     
- Misses         19       30     +11

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 03b4fc7...4315c1d. Read the comment docs.

This should now be feature complete.

The code is still pretty ugly,
and I still have tests that test the implementation details commented out (because the implementation details have changed, dramatically)
But it is passing all integration tests.
`

It also needs rebasing/squashing pretty badly too, I think.

The version I just pushed should have addressed all of @omus 's comments.
It is now ready for round 2 of review.

We are doing nested overdubbing, though I imagine not more than 2 deep normally
so when JuliaLabs/Cassette.jl#97 (comment)
lands, we should use that maybe and disable our hooks

This needs to be updated to Cassette 0.2
I am not sure what that entials yet

I have upgraded the Cassette version

I'm wondering if this would make Mocking a good solution to the issue of connection information with AbstractPath types in Filepaths.jl? Basically, I think it'd be nice if you could patch calls to write(path::FTPath, data, nothing) with write(path::FTPPath, data, c) where c is an FTPClient defined in some application code away from the write call.

rofinn/FilePaths.jl#36

I wouldn't say Mocking is a nice way to do that, but using similar Cassette stuff could be,
If not for some of the special cases needed for Mocking (like storing a set of patches for later, and matching the existing API, and dealling with all the ways a user could write a function), then Cassette usage would be a lot less complex.

Probably better to discuss in FilePathBase.jl#36 about it.

I'm getting serious about reviewing this during JuliaCon

I spent a bunch of time experimenting with Cassette based Mocking. At the moment there seems to be some serious performance issues using Cassette for this use case. Additionally I found several techniques we and apply to the existing @mock setup and will be making a few PRs to get those in place. These changes also are useful for switching to Cassette.

I'll close this PR as the integration with Cassette has significantly changed. The most recent update on this can be found here: #53 (comment)