I am trying to figure out why this is not happening on the app I am using mox in. But I guess it simply boils down to me being lucky and compilation order being luckily correct for me.
I submitted a pull request and this should be resolved in next version :).
Mine had the problem only on clean builds, it took a while to find that was happening since I had the module to be mocked already compiled when I first added the dependency and everything was ok
I figured it out why it works for me. I have 3 apps in umbrella, and I only mock the interactions where one calls another. So I suppose in my case the clean build works since the app I am about to mock is already always fully compiled (is in_umbrella dependency).
Just as reference for readers, the pull request @hubertlepicki openend that includes the fix is Use Code.ensure_compiled? vs Code.ensure_loaded? to ensure the module is available by hubertlepicki · Pull Request #17 · dashbitco/mox · GitHub
I was experiencing this as well. My solution involved using use MyApp.MyBehaviour. This required that I implement def __using__(_) as so:
defmodule MyApp.MyBehaviour do
@moduledoc """
Behaviour definition
"""
@type entry_attrs_t::map
@callback create_entry(entry_attrs_t) :: any
def __using__(_) do
end
end
and then in test/support/mocks.ex:
use MyApp.MyBehaviour
defmodule Mocks do
@moduledoc false
end
Mox.defmock(MyApp.MyMock, for: MyApp.MyBehaviour)
kinda hacky, but not horrible…
Turns out the real solution was to upgrade the version 
Didn’t realize I had pinned it at 0.1.0 (C&P from web page, DOH)
Turns out the real solution was to upgrade the version
Didn’t realize I had pinned it at 0.1.0 (C&P from web page, DOH)
Running mix hex.outdated every so often surfaces those things 