gmile

An issue with mock library

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 1419 4

2022-11-03 15:55:15 UTC

Marked As Solved

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

Last Post!

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