Need help with testing and Mox

Questions / Help
,
1

Hello!

So not so long ago I started learning Elixir (coming from python myself). To ease it up, I started a small project for myself(link). And I am trying to cover the module with tests.
I need an extremely easy thing - mock a function in my module in the tests. So I’ve decided to follow this article

To be more specific:

  1. I need to mock this function
  2. This function is used in function get_config_from_file and i want to test this function.
  3. I define a mock of this module with mox: link
  4. I try to use this mock in a test: link
  5. But when I try to call a function get_config_from_file from this mock, I get an error:
1) test config from file (Spacebrew.Config.Test)
 test/configuration_test.exs:8
 ** (Mox.UnexpectedCallError) no expectation defined for Spacebrew.ConfigMock.get_config_from_file/1 in process #PID<0.193.0>
 code: assert Spacebrew.ConfigMock.get_config_from_file(
 stacktrace:
   (mox) lib/mox.ex:551: Mox.__dispatch__/4
   test/configuration_test.exs:15: (test)

I understand that it says I should write an expect for the function i call. But why? I need it to be an original function from the module and only a paths function to be mocked.

I understand that I am wrong conceptually, I just don’t understand where and when :
Please help, as I am getting frustrated :cry:

1 Like
2

You already have part of the setup to get it to work… In Spacebrew.Config, you define @callback but also provides the implementation which does not make sense.

  • The callbacks should be definde in an “abstract” module
  • The runtime binding (ie module, with @behaviour Spacebrew.Config) should be defined in config.exs
  • You already defined a “virtual” module in test_helper.exs

Since your mock is a virtual module implementing the behaviour, any function required in the scope of a test needs to be mocked.

1 Like
3

Thanks for the answer!

So, basically, mox forces me to make additional abstract modules? Or creating proxy modules for the functions I want to mock? This, to be fair, sounds like a ridiculous overcomplication

4

So the issue here is that mox doesn’t use your implementation in lib/configuration.ex. All of the callbacks your behaviour has are expected to be different for your mock and must therefore either be expected to be called or at least stubbed with the functionality mox provides. The mock does not inherit functionality from anywhere it just know’s the contract it needs to apply to.

I hope you’re already aware of the reasons for using behaviours as requirement in mox (if not just ask), but behaviours are the written contract about what different implementing modules need to provide as functions so the system using those modules does work. So think less of it as “switching out a function, which is currently inconvenient”, but more like “switching out one piece of stand-alone functionality for another”. Behaviours make sense for e.g. gen_servers, where boilerplate functionality is provided by otp, but the details are supplied by the user. It also makes sense when using an adapter pattern like in ecto switching out databases or in bamboo/swoosh switching out email providers.

For your paths functionality I’m really wondering if you really need a behaviour (and therefore mock) in there or if your implementation is not flexible enough to get those paths (optionally) passed from a higher level entrypoint, so you can simply pass different values from your test.

2 Likes
5

Perhaps you are not familiar with Classical (Detroit) vs Mockist (London) Testing.

The classical (pre-mock) approach has been to make test doubles injectable by design, e.g.:

  # in the "API" module
  def get_config_from_file(params),
    do: get_config_from_file(params, &paths/0)

  # perhaps in an "implementation" module
  def get_config_from_file(params, paths) do
    Enum.reduce(paths.(), params, fn x, acc ->
      read_file(x)
      |> case do
           {:ok, content} ->
             Logger.info "\"#{x}\" file found, parsing"
             struct!(acc, parse_data(content))
           {:error, error} ->
             Logger.info "\"#{x}\" file reading error: #{error}"
             acc
         end
    end)
  end
4 Likes
6

Thanks a lot for your answer, that is what I needed!