An issue with mock library

gmile

It appears I am doing something off, as after mocking a module using mock, the module is completely unloaded from memory and subsequent code that depends on the module being there fails.

As a working proof of concept, the following script fails - the error is raised every time execution gets to run the last line, e.g. MyModule3.my_fun(1):

Mix.install [:mock]

defmodule MyModule1 do
  def my_fun(arg) do
    arg + 1
  end
end

defmodule MyModule2 do
  import Mock

  def my_fun(_arg) do
    with_mock(MyModule1, my_fun: fn _number -> 123 end) do
      MyModule1.my_fun(1)
    end
  end
end

MyModule1.my_fun(1) |> IO.inspect
MyModule2.my_fun(1) |> IO.inspect
MyModule1.my_fun(1) |> IO.inspect

The failure is:

$ elixir example.exs
2
123
** (UndefinedFunctionError) function MyModule1.my_fun/1 is undefined (module MyModule1 is not available)
    MyModule1.my_fun(1)
    example.exs:27: (file)
    (elixir 1.14.1) lib/code.ex:1245: Code.require_file/2
$

After digging a little, the mocking code appears to be reasonably straightforward, which leaves me quite puzzled as to what’s going on:

https://github.com/jjh42/mock/blob/f3580cb68692b41ee59e9784ba253473dab9420d/lib/mock.ex#L340-L368

Trivia:

elixir --version
Erlang/OTP 25 [erts-13.1.1] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit:ns]

Elixir 1.14.1 (compiled with Erlang/OTP 25)

4 comments

#testing #mocking

0 1650 4

2022-11-03 15:55:15 UTC

Showing Posts 1 to 4

Show Best Posts
Show All (oldest first)
Show All (newest first)

al2o3cr

mock_modules isn’t intended to be used outside that module, because it doesn’t completely un-mock things - all the places in Mock that call mock_modules eventually either invoke :meck.unload/0 or :meck.unload/1 like this:

https://github.com/jjh42/mock/blob/f3580cb68692b41ee59e9784ba253473dab9420d/lib/mock.ex#L324-L336

Post #1

gmile

Sorry if a kindergarten question, but how would I use Mock in a way that un-mocks mocked modules then?

Likely mistakenly, I was under an impression that mocking is only in effect in the scope of with_mock’s being/end block.

Expecting that perhaps unloading meck explicitly will solve the problem (e.g. bring back modules to their original un-mocked state), I just tried adding :meck.unload() right before the problematic line - this didn’t helped, the problem is still there:

MyModule1.my_fun(1) |> IO.inspect
MyModule2.my_fun(1) |> IO.inspect
:meck.unload()
MyModule1.my_fun(1) |> IO.inspect

Btw, I only mentioned mock_modules in my original module because, with_mock used in my example eventually boils down to calling mock_modules.

Post #2

al2o3cr

:meck.unload doesn’t “put the module back”, it unloads it entirely (from the docs):

This will purge and delete the module(s) from the Erlang virtual machine. If the mocked module(s) replaced an existing module, this module will still be in the Erlang load path and can be loaded manually or when called.

Future calls like MyModule1.my_fun will try to load MyModule1 from disk, but if it’s not compiled it won’t be found at all.

For instance, I made your example pass by extracting MyModule1 to on_disk.ex (the name is arbitrary, but the ex is important):

defmodule MyModule1 do
  def my_fun(arg) do
    arg + 1
  end
end

and then compiling it with elixirc on_disk.ex.

Then running the remainder as elixir example.exs prints out:

2
123
2

as expected.

Post #3

gmile

@al2o3cr thank you, your notes were instrumental in helping us understand what was going on with mocking in our case!

While my example above ended up being overly simplified, our actual situation turned out to be much more involved. I will describe it below, but a word of warning: it will sound like it’s not related to what has been so far discussed in this thread

We were mocking something in a test, and seeing the whole test suit stop working as a consequence of that. A suite would throw a cryptic error saying that such and such process name cannot be located.

It turned out that, at the time of mocking the specific module (and as you pointed out, that modules’ code being completely unloaded from memory), code from that module also happened to be running in the background (which is by design).

We were mocking a call to :hackney.request, and there was some code in the background that was executing a long-running :hackney.request. Our module happens to be a part of app supervision tree, so unloading :hackney from memory resulted in taking down entire app (e.g. during test suite run) with it.

Conclusion: take great care if you absolutely must use Mock library. Avoid it altogether if you can.

Post #4

— All posts loaded —