Dialyzer: inferring types when using Mox

The approach as stated does loose type information, but not because of mox or behaviours, but because of the runtime selection of the used implementation. No static analysis can catch errors based on information not available statically in the code.

If you make impl() return MyImplementation statically or correctly hardcode the typespec return value of it as MyImplementation then dialyzer can help you. But loosening the type information to not return a specific module means dropping to any module(), which is an alias for atom(). There’s nothing to check if the returned module is unknown.

The typesystem dialyzer uses doesn’t allow you to say “but the module returned implements that behaviour”. It’s either one specific module or any module for that typesystem.

Given the typesystem doesn’t help you can however go the “statically known” route. If you don’t need runtime selection you can compile the configured implementation into the module statically.

@impl Application.compile_env(:dialyzer_mox_behaviours, :impl, MyImplementation)
@spec impl() :: module()
defp impl(), do: @impl

I realize that the compiler cannot know which module is being used at runtime, but i was hoping that returning a reference to the behaviour in the spec would give dialyzer the necessary information. The spec info is contained in the behaviour after all, which doesn’t change at runtime.

The compile_env example does indeed work, thanks for that tip! I often use mocks in some tests and the real implementation in others, so this isn’t ideal for me. I suppose it would be possible to change the module attribute at runtime, but that feels like it goes against the whole point of using Mox.

Second solution

Another possible solution could be to move the dynamic resolution into MyBehaviour:

defmodule MyBehaviourSolutionTwo do
  @callback get_integer() :: integer
  @spec get_integer() :: integer
  def get_integer, do: impl().get_integer()

  defp impl(),
    do: Application.get_env(:dialyzer_mox_behaviours, :impl, MyImplementationSolutionTwo)
end

defmodule DialyzerMoxBehavioursSolutionTwo do
  @doc """
  Dialyzer error appears!
  """
  @spec dialyze_me_two() :: binary
  def dialyze_me_two, do: MyBehaviourSolutionTwo.get_integer()
end

There is some more duplication, and something about adding this code into the behaviour itself feels like a crime of code quality, but I think it would get the job done for me.

Third solution

Another thing i tried which seems preferable, but does not work, looks like this:

defmodule MyDispatcherSolutionThree do
  @behaviour MyBehaviourSolutionThree

  @impl MyBehaviourSolutionThree
  def get_integer, do: impl().get_integer()

  defp impl(),
    do: Application.get_env(:dialyzer_mox_behaviours, :impl, MyImplementationSolutionThree)
end

Add another implementation which uses the dynamic module. Does not give an error, even though I’m calling it statically as MyDispatcherSolutionThree.get_integer(). It works only when i explicitly copy the spec:

  @impl MyBehaviourSolutionThree
  @spec get_integer() :: integer
  def get_integer, do: impl().get_integer()

Doesn’t @impl MyBehaviourSolutionThree also inherit the spec information?

Mox.stub_with can help there.

I only considered stub_with to have some default functionality in the mock… Seems like a great idea to stub with an actual implementation, thanks!

I have a similar issue, but it’s actually the other way around. There is a client with a stubbed implementation or a real one being chosen at compile time. The stub is for testing/dev and always succeeds returning an {:ok, Res} tuple. The real implementation may fail with {:error, Error}. Since Dialyzer is run with the :test env, it returns The pattern can never match the type. in places in which the caller handles error return values. I want to avoid running Dialyzer in :prod env, and I’m not sure how to deal with this issue.

You could go with the approach the elixir codebase takes: