I’m sharing a pattern I’ve been tooling with. More or less, it’s an Elixir implementation of a Service Locator pattern (which is dubbed as an anti-pattern by some, but I feel like the realities of functional programming make some of the normal drawbacks less severe and overall a net positive).
This pattern is used thoroughly by PHP’s Laravel framework (and others), and is encapsulated quite cleanly in the PHP Pimple Package (yes, that’s an awful name). I confess that I personally never liked Python or Ruby’s monkey-patching approach to testing: I much prefer the explicit elegance of dependency injection that I think PHP does surprisingly well.
In Elixir, this pattern can be implemented without much fuss by using Application.get_env/2 and Application.put_env/3. Although it’s not strictly necessary, the syntax of this pattern is much more pleasing if you have a convenience function like the following defined for your app:
def app(key), do: Application.get_env(:my_app, key)
(The function name app here I’m borrowing directly from Laravel’s app function – but choose whatever name you want).
And then, in your config, you can define your “service” modules:
# config.exs
import Config
config :my_app,
json_module: Jason,
http_client: HTTPoison,
stripe_client: StripeModule
# ... etc ...
This allows us to elegantly call our configured modules, e.g.
# assume: `import MyApp`
app(:http_client).get("http://some-url.com")
AND we can override the modules with mocks for testing by using Application.put_env/3.
For example, if I wanted to test what happens if my HTTP get request returns a 404, I can mock this in a module. It helps if I configure my mix.exs
def project do
[
elixirc_paths: elixirc_paths(Mix.env()),
# ... etc....
]
end
defp elixirc_paths(:test), do: ["lib", "test/support"]
defp elixirc_paths(_), do: ["lib"]
then I can add my mocks inside the test/support/ directory, e.g.
defmodule MyApp.Mocks.HttpClient404
def get(url) do
{:error, "Probably this is more believable if you actually pasted in an actual error from a REAL 404 response"}
end
end
Then my test can do something like:
# Use a setup block with `on_exit` to ensure all configured modules are put back into place after each test
setup do
http_client = Application.get_env(:my_app, :http_client)
on_exit(fn ->
Application.put_env(:my_app, :http_client, http_client)
end)
end
test "invalid URLs generate 404" do
Application.put_env(:my_app, :http_client, MyApp.Mocks.HttpClient404)
assert {:error, _} = MyApp.do_something_that_calls_http_client()
end
Hopefully that makes sense. This doesn’t seem like a perfect solution, but it doesn’t feel completely smelly either: it lets me test all aspects of 3rd party services going bezerk, and that’s a big win. The syntax smoothing is a nice bonus too.
Hopefully this is helpful to someone (and I sincerely hope I’m not pedaling nasty anti-patterns here).
