we use Mox extensively for our unit testing (although perhaps you disagree that we are unit testing). I tend to agree with @LostKobrakai that making the multiple implementations of a function/module explicit via a behaviour benefits the code by defining an explicit contract.

Also in case you’re not aware with Mox it is very easy for the mocked module to return different values when it is called a second or third time:

test "email sending is handled" do
  MyApp.Test.MockEmailSender
  |> Mox.expect(:send_email, fn _email_text -> {:ok, :sent} end)
  |> Mox.expect(:send_email, fn _email_text -> {:error, :remote_server_offline} end)
  
   # When this calls `MockEmailSender.send_email/1` it will return `{:ok, :sent}`
  MyApp.notify_user("hi")

  # When this calls `MockEmailSender.send_email/1` it will return `{:error, :remote_server_offline}`
  MyApp.notify_user("bye")
end

Also that test above works perfectly with async: true even if you’re running code with Tasks (as long as you’re using Elixir 1.8+).

Sometimes I also stub a Mock to run the actual code. That looks like:

Mox.stub(MyApp.Test.MockEmailSender, :send_email, &MyApp.EmailSender.send_email/1)`

One last thought, I’ve found that using a Mock with an explicit contract lines up very well with the “functional core, imperative shell” school of thought.

But you also introducted the idea of injected dependencies, which need to be set somewhere. And that somewhere is most often some global entity, unless you can inject from within the test itself. If you indeed can inject from the test then you should be just fine with e.g. mox Mox — Mox v0.5.0 even if multiple processes (concurrent testing) are involved.

Edit: The difficult part here is how to let :get_fn be aware of where to send data like “I was called with args”, so that the test can check those. If you can directly inject e.g. the pid of the test (and each test has it’s own pid) then the rest is just implementation of sending the correct data back.

It depends on the my_lib and there is few possible approaches to that:

Mock my_lib

You can use for example mockery in form of:

def my_request(val) do
  mockable(MyLib).get("some_website/val")
end

And then in your test you can use:

test "calls MyLib.get/1" do
  mock MyLib, [get: 1], fn _data -> System.unique_integer() end

  Subject.my_request(10)

  assert_called MyLib, get: 1
end

Or if you want sequence of numbers

test "calls MyLib.get/1" do
  counter = :counters.new(1, [])

  mock MyLib, [get: 1], fn _data ->
    :ok = :counters.add(counter, 1, 1)
    :counters.get(counter, 1)
  end

  Subject.my_request(10)

  assert_called MyLib, get: 1
end

Or if you are using Erlang <21.2

test "calls MyLib.get/1" do
  pid = start_supervised!({Agent, 0})

  mock MyLib, [get: 1], fn _data ->
    Agent.get_and_update(pid, &{&1 + 1, &1 + 1})
  end

  Subject.my_request(10)

  assert_called MyLib, get: 1
end

Mock HTTP client

Assume that my_lib use Tesla library for requests then you can use:

setup do
  Application.put_env(:tesla, MyLib.HTTPClient, adapter: Tesla.Mock
end

test "API does request to `http://example.com`" do
  mock fn ->
    %{method: :get, url: "http://example.com/hello"} ->
        %Tesla.Env{status: 200, body: "#{System.unique_integer()}"}
  end

  Subject.my_request(10)
end

Mock target service

If target URL is configurable then you can use solution like Bypass to create fake target of the request instead of mocking MyLib or HTTP client. I used this solution for testing S3 backends in my projects.

So as you can see, there is plenty of possible solutions, and Elixir by default do not force one approach over another, which IMHO is good thing.