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
At WyeWorks, we believe great software is built by combining technical excellence with genuine human connection
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.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 12 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
Ninigi
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
- 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.
LostKobrakai
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.
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!
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
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).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
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!
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
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
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 alias