Need help with testing and Mox

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.

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

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.

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

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