How to mock HTTPoison with Mox?

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.

I see your solution uses different implementations depending on the MIX_ENV. While not completely wrong, I would like my tests to be independent from which ENV they run on.
This is actually one of the issues Mox tries to solve:

I think this is exactly what the article is suggesting.

quoting from the article

# In config/dev.exs
config :my_app, :twitter_api, MyApp.Twitter.Sandbox

# In config/test.exs
config :my_app, :twitter_api, MyApp.Twitter.InMemory

# In config/prod.exs
config :my_app, :twitter_api, MyApp.Twitter.HTTPClient

It would appear you are correct!
Sorry for the misdirection on my part!

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.

I second @peerreynders’ call-out. You should not mock HTTPoison, but mock the higher level module that is using HTTPoison to get data. For example, if you use HTTPoison to call an HTTP API returning the temperature outside, create a module representing the weather service, with a function for getting the current temperature, and mock the weather service module.

I am afraid I disagree with this. I don’t want to test the higher module that uses HTTPoison. I know it works. I have a suite of tests for that. What i need to know is if this module, let’s call it, TemperatureStats respects the contract HTTPoison uses. The only way to do this, to know this, is to mock HTTPoison and to make sure I am calling it’s functions with the correct parameters, i.e., that I am invoking HTTPoison with the correct headers, URL, etc.

If there is a better way to do this, I don’t know.

@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.

Is this bad? good? Some people defend we shouldn’t test these things leave them to QA or for a complete suite of slow integration tests. I can see the argument there, but in my experience, when you leave something for someonese else to test another time, reality dictates that nothing gets actually done, and so in the end the real testers will be your users. To me this is not acceptable, so I unit test everything.

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.

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:

• HTTPoison
• HTTPoison.Base