Wrong unused warnings in Elixir


I have a test that defines modules which use a behaviour. To save some typing I am using an alias for the behaviour module when I use it in my tests. However the compiler doesn’t see it and plasters my screen with unused warnings.


defmodule MyApp.DispatcherTest do
  use ExUnit.Case

  # Contract 
  alias MyApp.Dispatcher.Backend
  # SUT
  alias MyApp.Dispatcher

  test "calls request_fn with the correct parameters" do

    defmodule MyApp.Dispatcher.Backend.MissTest do
      @behaviour Backend

      @impl Backend
      def match(_params), do: false

      @impl Backend
      def url(_params), do: "/bfg_division"

    defmodule MyApp.Dispatcher.Backend.HitTest do
      @behaviour Backend

      @impl Backend
      def match(_params), do: true

      @impl Backend
      def url(_params), do: "/family_jules"

    defmodule MyApp.Dispatcher.Backend.HitTest2 do
      @behaviour Backend

      @impl Backend
      def match(_params), do: true

      @impl Backend
      def url(_params), do: "/comatose"

    params = %{}
    test_pid = self()
    deps = [
      backends: [
      request: fn(name, url) ->
        send(test_pid, {:fire, {name, url}})
        {:ok, :received}

    Dispatcher.send(params, deps)

    expected_name = :hit_test
    expected_url = "/family_jules"
    assert_receive {:fire, {^expected_name, ^expected_url}}

    expected_name2 = :hit_test2
    expected_url2 = "/comatose"
    assert_receive {:fire, {^expected_name2, ^expected_url2}}


Inside the test I have 3 test modules (MissTest, HitTest, HitTest2), which implement the behaviour Backend. Each module implements 2 functions to comply with the contract of the behaviour.


The problem is that every time I run mix test I get this warning plastered onto my screen:

warning: unused alias Backend

Which is not true. To prove it, if I actually remove the line alias MyApp.Dispatcher.Backend then I get even more warnings, stating that behaviour Backend doens’t exist or is not specified.


  1. Why am I getting this warning?
  2. How can I fix it?
1 Like

I guess this is what’s happening:

You are defining your test backend modules within MyApp.DispatcherTest, so their final name is something like MyApp.DispatcherTest.MyApp.Dispatcher.Backend.MissTest, not MyApp.Dispatcher.Backend.MissTest.


And how would this confuse the compile exactly ?
Surely, if that was the case the tests should fail, because I am passing the modules directly into Dispatcher.send and it wouldn’t even compile, right ?

This is a (non-solvable) limitation in how the compiler detects that aliases are used. Once that file is compiled, the Backend has indeed not been used, because the other modules are only defined (and their contents only executed) when the test runs.

You have two options:

  1. Pass warn: false to the alias
  2. Move your module definition outside of the test and inside the module body

Thank you so much for your reply.
One final question.

Does this mean, in your opinion, that I am using a anti-pattern in my tests? Am I structuring my code so bad that I am hitting a compiler limitation? (Does this raise any flags to you?)

1 Like

I personally don’t think it is a bad flag, it is fine. But you can also move the modules out and the behaviour should be the same, so I would rather do that rather than use the warn: false flag, if that makes any sense.

1 Like

The issue I have with putting the modules outside is that as I add more tests and as I need more fake modules that implement the contract, I will end up with big pile of lose modules in my test suite that don’t connect clearly to any test I have - this is why I create the modules inside the test, this way all my tests are self contained.

I can always put the alias inside each module, that also works though. Thanks for chipping in!

Do all those modules also have different names? If not I’d consider that an issue, as modules are defined globally on the beam and not per test. If they indeed have unique names then you have a clear connection between test and module.

This is a good question. My SUT receives a list of modules that obey a given contract. The SUT then makes calls to those modules.

Ideally I would have each test with 1 or 2 modules that would be the same. But I can’t do that because module names Elixir have to be unique (they are global as you said) so I end up have 2 or 3 tests where I have modules with dumb names like MyApp.Test1, MyApp.Test2 and so on, even if the tests are independent between each other (I cannot repeat a module name in any other test once it was used in a single test because I get the redefining module warning).

Would it make sense in this case to have one TestBackend module and do the implementation with Mox? You would pass the same module multiple times though, I don’t know if that would makes things clearer, or more obscure.

Not a bad idea, but since I need several modules (several mox) I would have to still define them separately:

Mox.defmock(MyApp.MissTest, for: MyApp.Calculator)
Mox.defmock(MyApp.HitTest, for: MyApp.Calculator)
Mox.defmock(MyApp.HitTest2, for: MyApp.Calculator)

In the end, I would still end up with the same dummy names problem, but on the flip side I would have less lines of code :smiley:

Interesting suggestion!

At least the dummy names would no longer need to be coupled to a certain behaviour, but are just “dummy names”. The behaviour would be defined in each test. But as always it comes with the tradeoffs of mox in terms of async tests.

It was late in the day for me, and I honestly didn’t want to spend any time on thinking about your problem in depth, so I just threw in what I thought at that moment in the form of a question. I didn’t even think about defining the modules in your tests - should have been obvious :slightly_smiling_face: - but what jumped out to me was the fact that you did not really care about where the logic for the return value you needed was defined, as long as the return values satisfies your test case. That looked like the perfect example for a mock to me, and you already defined the behaviour, so why not go for Mox.

The way I thought you might want to use it is define one or two mock modules in your test helper, and call the same module(s) multiple times with different return values. That way, the return value would be obvious from the tests and you wouldn’t have to define the modules over and over again.

However, my experience with Mox is limited to communication layers of an app - mainly in the actual implementation of the communication, think HTTP connectors that implement get, post, put, patch and delete - so my suggestion might not be suitable for you at all.

1 Like