Mock a module only from the perspective of a specific caller (calling process)

[eproxus]

It should be possible to mock a module so that a set of processes sees the mocked module and all other processes sees the original module.

• mock:new(mymod, [{restrict, pid()}]):
  • only the caller pid() would hit the mocked module
• or even better, all pids belonging to a specific application
• Would enable mocking of the inet, gen_tcp modules etc

[eproxus]

Closing and documenting in the wiki instead: https://github.com/eproxus/meck/wiki#feature-ideas

Please comment here if you have information or requests to add, and/or want to discuss a PR or possible implementation proposal.

[techgaun]

@eproxus has any work been done on this? Am interested to know the updates as I don't think there's anything for this right now. Also, the links to the issues on wiki are pointing to incorrect links and have to include meck in the url. I believe this is the way to make it possible to run tests in parallel even if they are mocking the same modules.

I would be interested to look at this by looking at how it is right now and what can be done but might need some assistance.

[eproxus]

@techgaun No, no work has been done so far. The only way to current achieve this is to create your own fun which checks the calling process (the fun runs in the process that calls the mock, so it should be able to use self() and then do something special, otherwise call meck:passthrough()).

As for an official solution, I see two options:

1. Deal with this in the mock process (i.e. the official solution of the workaround above)
2. Actually change the calling module, which is much trickier and needs it's own management (monitoring process, backup, etc.).

(2) of course then limits the calls to only work from a certain module, but I think this is the better option anyway. This is also the only reliable way to mock "system" and ENIF/driver modules such as gen_tcp etc. It is way more complex than (1), but I'm also not keen on implementing (1) since it can be implemented quite easily manually anyway (it might be a good candidate for an external helper library for Meck).

(Thanks for notifying be about the broken links, I've fixed them)