Sorry to drag this thread back up, but it is now the #1 hit for the UnexpectedCallError in the OP. Just to note that beyond the more esoteric situations discussed in the thread so far, you can also see this error via a simple race condition. This situation is discussed in the doco under Blocking on Expectations at Mox — Mox v1.0.1. It also comes up a few times in the closed Mox issues. Basically if the test finishes before any spawned processes then Mox will tear down the expectations before the tested behaviour uses it. Can be very confusing as you may partial mock hits where it is set to expect multiple hits. One way around it is to force the test to wait by messaging from within the mock. From that doco:

test "calling a mock from a different process" do
  parent = self()
  ref = make_ref()

  expect(MyApp.MockWeatherAPI, :temp, fn _loc ->
    send(parent, {ref, :temp})
    {:ok, 30}
  end)

  spawn(fn -> MyApp.HumanizedWeather.temp({50.06, 19.94}) end)

  assert_receive {^ref, :temp}

  verify!()
end

Hope that helps someone in a similar situation!

This approach seems to work (when setup :set_mox_global doesn’t):

defmodule MockShare do
  import Mox

  def init(args) do
    MyApp.CalcMock
    |> expect(:add, fn x, y -> x + y end)
    |> expect(:mult, fn x, y -> x * y end)

    {:ok, args}
  end

  def handle_call({:share, pid}, _from, state) do
    Mox.allow(MyApp.CalcMock, self(), pid)
    {:reply, :ok, state}
  end

  # ---

  def child_spec(_args),
    do: %{
      id: __MODULE__,
      start: {__MODULE__, :start_link, []},
      restart: :permanent,
      shutdown: 5000,
      type: :worker
    }

  def start_link(),
    do: GenServer.start_link(__MODULE__, [])

  def share(share_id, pid),
    do: GenServer.call(share_id, {:share, pid})
end

defmodule MyAppTest do
  use ExUnit.Case, async: true

  import Mox

  def share_mock(_context) do
    {:ok, share_pid} = start_supervised(MockShare)

    [share_pid: share_pid]
  end

  setup_all :share_mock
  setup :verify_on_exit!

  test "Use add expectation in task", context do
    MockShare.share(context.share_pid, self())

    task = Task.async(fn -> MyApp.CalcMock.add(2, 3) end)
    result = Task.await(task)
    assert result == 5
  end

  test "Use mult expectation in task", context do
    MockShare.share(context.share_pid, self())

    task = Task.async(fn -> MyApp.CalcMock.mult(2, 3) end)
    result = Task.await(task)
    assert result == 6
  end
end

Mox.allow/3

The only way I could get global mode to work:

defmodule MyAppTest do
  use ExUnit.Case

  import Mox

  # setup :set_mox_global - doesn't work

  setup_all do
    expect(MyApp.CalcMock, :add, fn x, y -> x + y end)
    expect(MyApp.CalcMock, :mult, fn x, y -> x * y end)
    set_mox_global()
    %{}
  end

  test "Use add expectation in task" do
    task = Task.async(fn -> MyApp.CalcMock.add(2, 3) end)
    result = Task.await(task)
    assert result == 5
  end

  test "Use mult expectation in task" do
    task = Task.async(fn -> MyApp.CalcMock.mult(2, 3) end)
    result = Task.await(task)
    assert result == 6
  end
end

The way I understand the documentation this should only work in global mode …

defmodule MyAppTest do
  use ExUnit.Case, async: true

  import Mox

  setup [:set_mox_private, :verify_on_exit!]

  def add,
    do: MyApp.CalcMock.add(2, 3)

  def mult,
    do: MyApp.CalcMock.mult(2, 3)

  test "Use add expectation in task" do
    expect(MyApp.CalcMock, :add, fn x, y -> x + y end)
    task = Task.async(&add/0)
    result = Task.await(task)
    assert result == 5
  end

  test "Use mult expectation in task" do
    expect(MyApp.CalcMock, :mult, fn x, y -> x * y end)
    task = Task.async(&mult/0)
    result = Task.await(task)
    assert result == 6
  end
end

and yet the task process has no problem using the mocked functions.

There’s a note about this below the example - on Elixir 1.8+ Mox can use $callers to detect when a parent process has an expectation set. (see also the similar machinery in DBConnection)

That’s not going to help for your case, though, since the test process and the registry aren’t related in a parent->child sense.

I don’t know if you should be using it like that in first place. You are attempting to mock the piece of infrastructure you are in control, and mocking/stubbing in my mind should be reserved to dealing with elements of infrastructure you don’t have control over: like remote services/endpoints, systems talking to external systems etc.

If you don’t want to touch ExRegistry in your tests, you could write a testing module that does something similar that makes sense in your test and inject it in it’s place for testing purposes, or isolate the worker further and test it in isolation.

A quick scan of the source code suggests to me that expectations are registered by process id - if that is true the same expectation would have to registered by/for the pool process.