Mpanarin
Need help with testing and Mox
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:
- I need to mock this function
- This function is used in function
get_config_from_fileand i want to test this function. - I define a mock of this module with mox: link
- I try to use this mock in a test: link
- But when I try to call a function
get_config_from_filefrom 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 
Marked As Solved
peerreynders
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
Also Liked
LostKobrakai
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.
gcauchon
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 inconfig.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.
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
The deployment platform built for Elixir: PaaS ease, VPS control.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Real-time error tracking, performance insights, and observability for devs.
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
Courses that'll move you from confusion to "Aha, now I get it!"