Dialyzer: inferring types when using Mox

Questions / Help
, ,
1

I ran into this issue the other day and it’s been bugging me ever since. Below is a basic behaviour/implementation, and function which returns a module at runtime. This is the recommended way to decouple your modules when using Mox. It seems to me that this breaks Dialyzer analysis, since no errors are produced with this clearly incorrect typing.

defmodule MyBehaviour do
  @callback get_integer() :: integer
end

defmodule MyImplementation do
  @behaviour MyBehaviour

  @impl MyBehaviour
  def get_integer, do: 100
end

defmodule DialyzerMoxBehaviours do
  @moduledoc """
  Using the recommended implementation of a behaviour for Mox, Dialyzer is unable to infer the type of `get_integer()`.
  By decoupling this module from `MyImplementation`, we lose the typespec information from the behaviour.
  """

  @spec dialyze_me() :: binary
  def dialyze_me, do: "hello" # valid type

  @spec dialyze_me_two() :: binary
  def dialyze_me_two, do: impl().get_integer() # invalid type, but dialyzer does not complain.

  @spec impl() :: MyBehaviour
  defp impl(), do: Application.get_env(:dialyzer_mox_behaviours, :impl, MyImplementation)
end

Am I missing something? I like using Mox but this seems like a major drawback to me. If anyone else has encountered this issue I’m interested in how you’ve solved it.

2

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
4 Likes
3

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?

4

Mox.stub_with can help there.

3 Likes
5

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!