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.
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:
Pass warn: false to the alias
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?)
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.
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.
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 - 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.
- 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.
