This is an interesting topic and something I’ve tried to figure out myself lately as I’m working on an Elixir project at work.
I really dislike mocking too much, and try to keep that for 3rd party APIs that are almost always mocked.
What I’ve seen though is when you have long call chains with side-effects in the end. Then it becomes annoying as it makes all functions “impure”.
Say you have this (never mind any error handling):
defmodule MessageProcessor do
def process(message) do
message
|> Parser.parse()
|> MessageHandler.handle()
end
end
defmodule MessageHandler do
def handle(message) do
case verify_message(message) do
:ok -> Router.route(message)
{:error, reason} -> {:error, reason}
end
end
end
defmodule Router do
def route(%FooMessage{} = message) do
ExternalAPI.call(message)
end
def route(%BarMessage{} = message) do
AnotherExternalAPI.call(message)
end
end
If you test the Router module it’s quite straight forward. You can update it to inject the external API module, or set a mock globaly using Mox.
But, then when you want to test the MessageHandler and MessageProcessor - they also end up calling the 3rd party.
So for MessageProcessor for example, your alternatives are:
- Write a behaviour for the MessageHandler module and inject a mock. Don’t like mocking internal modules…
- If the 3rd party API mocks are set globally, you need to add
expect(...) calls in the MessageProcessor tests. Not sure if that makes sense. You’d do the same for MessageHandler tests…
- If the 3rd party API mocks are not set globally, you need to inject them all the way from MessageProcessor → MessageHandler → Router. Horrible
- Rewrite the code.
Lately I’ve been leaning more to 4 when I see code like this, trying to isolate the side effects.
Something like this:
defmodule MessageProcessor do
def process(message) do
with {:ok, parsed_message} <- Parser.parse(message),
{:ok, verified_message} <- MessageVerifyer.verify(parsed_message),
{:ok, {module, fun, args} <- Router.route(verified_message) do
apply(module, fun, args)
end
end
end
defmodule MessageVerifyer do
def verify(message) do
if good?(message) do
{:ok, message}
else
{:error, :bad_message}
end
end
end
defmodule Router do
def route(%FooMessage{} = message) do
{ExternalApi, :call [message]}
end
def route(%BarMessage{} = message) do
{AnotherExternalApi, :call [message]}
end
end
Now the MessageVerifyer and Router have no side-effects and can easily be tested. The MessageProcessor would not be “unit tested” but only integration tested (or whatever you want to call it), and I would mock the 3rd party API calls with either a global Mox mock or using Bypass or something. Since the MessageProcessor basically only “integrates” different parts of your codebase, a “unit test” doesn’t make much sense.
I feel like approaches like this helps a lot with dealing with (not) mocking etc. But, I don’t have that much experience with bigger Elixir projects yet though so we’ll see.
What do you think about that?
