This is what I eventually settled on as well but it feels very… unclean. Both a behaviour module and an implementation dispatcher. Two in one.
But I am the first guy around here to make a huge stink about having too many small files so yeah, I settled on that option and made myself hate it the least. 
I try to avoid introducing behaviour if this is only for test. If the behaviour already exists because the production code uses different implementations, then Mox all the way, but otherwise no. If the code calls an external thing such as an HTTP API we mock that with a real HTTP server. Even if it is controversial ; it works well in our case.
GenServers that do polling are just not started in test environment, and tested only in their own test. If the rest of the app must interact with it then we would rather have the GenServer only handle process stuff and delegate the logic to a functional module that will store the data somewhere, so we can call that directly in the tests to setup the data, and have the app interact with the data.
Wow, I provoked a huge wave of discussions, some of them are still beyond of my understanding. Thank you all for bringing your experience and knowledge stones to the base.
What confuses me most is that n my simple app, I have a GenServer defies to be started as a child process wen the app starts:
# application.ex
@impl true
def start(_type, _args) do
...
{PaymentServer.Exchange.RatesMonitor, []}
]
end
where the module RatesMonitor is a GenServer which hits an external API server every ‘X’ minutes.
I tried to define a behaviour module as follows:
defmodule PaymentServer.Exchange.MonitorApi do
@moduledoc """
Handles Exchange server API calls
"""
@callback get_rates(from_currency :: String.t(), to_currency :: String.t()) ::
{:ok, any()} | {:error, any()}
end
Then in a real API module I declare this behavour:
defmodule PaymentServer.Exchange.AlphaVantageApi do
@behaviour PaymentServer.Exchange.MonitorApi
@moduledoc """
This is a Alpha Vantage API module which provides the exchange rates data
"""
@api_url "http://localhost:4001/query"
@impl true
def get_rates(from_currency \\ "USD", to_currency \\ "JPY") do
url = build_search_url(from_currency, to_currency)
case Req.get(url) do
{:error, reason} -> {:error, reason}
{:ok, response} -> response
end
end
...
end
Then in the GenServer module, I call it as follows:
defmodule PaymentServer.Exchange.RatesMonitor do
@moduledoc """
This is the implementation of an exchange rates monitor server
"""
use GenServer
...
defp fetch_rates(%{from_currency: from_currency, to_currency: to_currency} = state) do
api_module =
Application.get_env(:payment_server, :api_module, PaymentServer.Exchange.AlphaVantageApi)
response = api_module.get_rates(from_currency, to_currency)
rate = Parser.parse(response)
%{state | from_currency: from_currency, to_currency: to_currency, rate: rate}
end
end
To be able to use a mock API module in tests, I created the following module:
defmodule PaymentServer.Exchange.MockAlphaVantageApi do
@behaviour PaymentServer.Exchange.MonitorApi
@impl true
def get_rates(from_currency, to_currency) do
"""
status: 200,
body: %{
"Realtime Currency Exchange Rate" => %{
"1. From_Currency Code" => "EUR",
"2. From_Currency Name" => "Euro",
"3. To_Currency Code" => "USD",
"4. To_Currency Name" => "US Dollar",
"5. Exchange Rate" => "3.2045",
"6. Last Refreshed" => "2024-03-31 16:47:21.920729Z",
"7. Time Zone" => "UTC",
"8. Bid Price" => "3.2045",
"9. Ask Price" => "3.2045"
}
},
"""
end
end
and put these lines in the config/tests.exs file:
config :payment_server,
api_module: PaymentServer.Exchange.MockAlphaVantageApi
A simple tests where I tried to check if the mock module would be used:
defmodule PaymentServer.Exchange.MockAlphaVantageApiTest do
use ExUnit.Case, async: true
test "it should call mocked API" do
response = PaymentServer.Exchange.MonitorApi.get_rates("eur", "usd")
IO.inspect response
end
end
Before running the test, I stopped the API running in a Docker container and run mix test test/payment_server/exchange/mock_alpha_vantage_api_test.exs which failed with:
** (Mix) Could not start application payment_server: PaymentServer.Application.start(:normal, []) returned an error: shutdown: failed to start child: PaymentServer.Exchange.RatesMonitor
** (EXIT) an exception was raised:
** (UndefinedFunctionError) function PaymentServer.Exchange.MockAlphaVantageApi.get_rates/2 is undefined (module PaymentServer.Exchange.MockAlphaVantageApi is not available)
PaymentServer.Exchange.MockAlphaVantageApi.get_rates(:usd, :eur)
(payment_server 0.1.0) lib/payment_server/exchange/rates_monitor.ex:64: PaymentServer.Exchange.RatesMonitor.fetch_rates/1
(payment_server 0.1.0) lib/payment_server/exchange/rates_monitor.ex:36: PaymentServer.Exchange.RatesMonitor.init/1
(stdlib 4.3.1.2) gen_server.erl:851: :gen_server.init_it/2
(stdlib 4.3.1.2) gen_server.erl:814: :gen_server.init_it/6
(stdlib 4.3.1.2) proc_lib.erl:240: :proc_lib.init_p_do_apply/3
So the question is why, despite all the above settings, the app could not start the GenServer module, PaymentServer.Exchange.RatesMonitor ?
It bothers me why to run tests, I still need to have API instance running in a Docker container? Even when using the above Mimic lib, (which mock fine the requests), it is still needed.
On a technical level this is indeed different, but on a functional level you have the interface in the form of an http api specification. Instead of switching out a module you’ll be switching out an endpoint. The only downside I see to this is that while you have an interface you’re not in control over the interface. The provider of the http api changing requirements breaks not just the integration with the actual API, but also all the rest of the codebase depending on the interface. If you wrap things in your own abstraction you can limit that blast radius.
This might also be a small push to define the interface by what the application needs rather than what the (current) provider provides.
module PaymentServer.Exchange.MockAlphaVantageApi is not available. This part of the error message is the key. It’s trying to call the correct module, but it’s not available. So the question would be where you put the module definition.
PaymentServer.Exchange.MockAlphaVantageApi module is defined in test/payment_server/exchange/mock_alpha_vantage_api.ex. Should it be absolutely somewhere in the lib directory?
By default only files in lib/ are compiled. Test files are scripts and called by the test runner. However in mix.exs you can add additional folders for source files to be compiled. Many elixir projects configure test/support to be such a folder for the test mix env: Add Elixir files to your compiled list - Today I Learned
On a technical level this is indeed different, but on a functional level you have the interface in the form of an http api specification. Instead of switching out a module you’ll be switching out an endpoint.
Yes but this interface has a single implementation in production code and so we test that only.
The only downside I see to this is that while you have an interface you’re not in control over the interface. The provider of the http api changing requirements breaks not just the integration with the actual API, but also all the rest of the codebase depending on the interface.
Indeed, if the HTTP API we depend on changes, we are screwed and have to chage the code. I don’t see how adding more layers to the story changes that infortunately. However I understand that you may get more time to change with more layers.
If you wrap things in your own abstraction you can limit that blast radius. This might also be a small push to define the interface by what the application needs rather than what the (current) provider provides.
Our production code that we test with a real http endpoint as a mock is our own abstraction, and provides what we need from that external dependency. If you add one more layer you still need to implement and test what to do when you get 400, 500, 403 errors etc.
What you get when splitting that in two parts is test speed, I concede, at the cost of more complexity.
Now if the endpoint returns {"hello": "world"} and our client returns %Greeting{who: "world"} then indeed we cannot just directly tell in the tests that the client will return that second form. But we can just pass that second form to the code that should handle it and test that it does. We just need one more test to be sure that there is “something” that will call the client and then pass that second form to the other part of the code.
In our app it works well like that because the “handler” part is dynamic and we can mock that with a simple module that will ensure that it receives the good data from a defined endpoint returned body. It depends on how things are layed out and there are so many possible ways to do things. Bottom line is I’d rather not add behaviours for the sake of tests.
The thing that actually sold me on passing an implementation as a function argument is the fact that in tests I can have it both ways: both async: true and clean-ish production code. I don’t like the idea very much but still, we can always have one more wrapping module e.g.
defmodule MyApp.GithubAPI do
def impl(), do: # fetch from env or w/e.
def get_forks(repo) do
MyApp.GithubClient.get_forks(impl(), repo)
end
end
This allows (more) parallel tests as it doesn’t modify the modules globally and also calms down readability fanatics like myself – we don’t have to carry implementations around like the useless friend who always gets drunk and has to be carried / driven home.
Req also has test stubs - Req.Test — req v0.6.2
But i am not sure what it is exactly that you are trying to test.
Do you want to test the PaymentServer.Exchange.RatesMonitor GenServer?
Or some other parts of your app that depend on this GenServer?