Fl4m3Ph03n1x
How to mock HTTPoison with Mox?
Background
I have library that uses HTTPoison for some functionality I need to test. To achieve this I am using Mox, which I believe is the universal mocking library for Elixir (even though there are others this one has the seal of approval of José Valim)
Problem
Everything is going fine, I define my mocks in the test_helpers.exs:
ExUnit.start()
Mox.defmock(HTTPoisonMock, for: HTTPoison)
And I set up my dummy tests:
defmodule Alfred.Test.Http.Test do
use ExUnit.Case, async: true
import Mox
# Make sure mocks are verified when the test exits
setup :verify_on_exit!
describe "get" do
test "works on OK" do
HTTPoisonMock
|> get(:get, fn _ -> 1 end)
assert HTTPoisonMock.get(1) == 1
end
end
end
The problem here is I can’t run them:
module HTTPoison is not a behaviour, please pass a behaviour to :for
Mock Contracts, not implementations
Now, I know José Valim supports this ideology, thus everything we should mock should have a contract. But HTTPoison is not mine and it doesn’t have one. So this brings me to the following question:
- How can I mock 3rd libraries that don’t offer behaviours using Mox ?
Marked As Solved
bonf
You can wrap HTTPoison with your own module.
This works for me:
define a behaviour
defmodule MyApp.Http.Adapter do
@callback get(url :: String.t(), headers :: list) :: String.t()
@callback post(url :: String.t(), body :: String.t(), headers :: list) :: String.t()
end
define the real implementation
defmodule MyApp.Http.Client do
def get(url, headers) do
response = HTTPoison.get(.....)
...
end
def post(url, body, headers) do
...
end
in config/test.exs
config :my_app, :http_adapter, MyApp.Http.Mock
for dev/prod
config :my_app, :http_adapter, MyApp.Http.Client
usage:
defmodule MyApp.Foo do
@http_client Application.get_env(:my_app, :http_adapter)
def bar() do
@http_client.post(url, payload, [])
end
end
in your test:
MyApp.Http.Mock
|> expect(:post, fn _url, _body, _headers ->
{:ok, %HTTPoison.Response{status: 200, body: ....}}
end)
Hope this helps.
Also Liked
sgyyz
As you can see HTTPoison it uses HTTPoison.Base directly. And HTTPoison.Base defines behaviors. Which means we can mock HTTPoison.Base instead of mock HTTPoison.
# config/config.exs
config :module_name, :httpoison, HTTPoision
# config/test.exs
config :module_name, :httpoison, MockHTTPoison
# test/support/mocks.ex
Mox.defmock(ModuleName.MockHTTPoison, for: HTTPoison.Base)
Reference:
peerreynders
If your test suite doesn’t break when you change HTTP client (and by default, when you change the contract the HTTP client is using) then it means you are not testing it at all.
I think there is a bit of misunderstanding here. The intent that I see behind that statement is that the HTTP client library is treated as an implementation detail. So there really are two approaches:
-
When testing, simply leave the HTTP client library in place. In a way this approach is similar to testing against a working, running database.
-
Establish a boundary between your code and the HTTP client library. I.e you design the contract while being constrained by the capabilities of the library.
Ultimately the second approach is consistent with Rainsberger’s “Narrowing API/Pattern of Usage API”. So in that case you would have your own HTTP client behaviour module which acts as the interface for the Happy Zone while the callback module interfaces with HTTPPoison in the DMZ to complete the DMZ adapter.
For your micro tests you use a faux callback module when performing collaboration tests. Much less frequently you run contract tests with the real callback module and HTTP client library to show that the contract implementation is still behaving in the expected way (Clearing Up the Integrated Tests Scam).
So now we’re just back at to the post that you’ve already marked as the solution.
peerreynders
Interestingly that article links to a google groups topic:
Your integration tests should not mock HTTPoison calls. A very simple way to see this is: if you replace HTTPoison by another HTTP client, should your integration test suite break? Probably not, your app behaviour is still be the same.
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Catch errors, track performance, monitor hosts and more.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance
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.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
Courses that'll move you from confusion to "Aha, now I get it!"