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 ?

9 comments

#testing #mox #httpoison

24 6229 9

2019-04-25 03:28:40 UTC

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.

Post #2

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:

Post #10

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.

Post #9

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.

Post #6

easco

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.

Post #7

Fl4m3Ph03n1x

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.

Post #8