Fl4m3Ph03n1x
Background
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.
Code
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"
end
defmodule MyApp.Dispatcher.Backend.HitTest do
@behaviour Backend
@impl Backend
def match(_params), do: true
@impl Backend
def url(_params), do: "/family_jules"
end
defmodule MyApp.Dispatcher.Backend.HitTest2 do
@behaviour Backend
@impl Backend
def match(_params), do: true
@impl Backend
def url(_params), do: "/comatose"
end
params = %{}
test_pid = self()
deps = [
backends: [
MyApp.Dispatcher.Backend.HitTest,
MyApp.Dispatcher.Backend.HitTest2,
MyApp.Dispatcher.Backend.MissTest
],
request: fn(name, url) ->
send(test_pid, {:fire, {name, url}})
{:ok, :received}
end
]
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}}
end
end
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.
Problem
The problem is that every time I run mix test I get this warning plastered onto my screen:
warning: unused alias Backend
test/myapp/dispatcher_test.exs:4
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.
Questions
- Why am I getting this warning?
- How can I fix it?
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Build Elixir applications with speed and confidence.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Bringing learning, work and compliance together since 1987.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
zwippie
I guess this is what’s happening:
You are defining your test backend modules within
MyApp.DispatcherTest, so their final name is something likeMyApp.DispatcherTest.MyApp.Dispatcher.Backend.MissTest, notMyApp.Dispatcher.Backend.MissTest.Fl4m3Ph03n1x
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.sendand it wouldn’t even compile, right ?josevalim
This is a (non-solvable) limitation in how the compiler detects that aliases are used. Once that file is compiled, the
Backendhas indeed not been used, because the other modules are only defined (and their contents only executed) when the test runs.You have two options:
warn: falseto the aliasFl4m3Ph03n1x
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?)
josevalim
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: falseflag, if that makes any sense.Fl4m3Ph03n1x
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!
LostKobrakai
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.
Fl4m3Ph03n1x
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.Test2and 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 theredefining modulewarning).Ninigi
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.
Fl4m3Ph03n1x
Not a bad idea, but since I need several modules (several mox) I would have to still define them separately:
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
Interesting suggestion!