dcrck
Testing the absence of optional dependencies within a library
I am adding various client adapters as optional dependencies for a library, much in the way :tesla does and as described here (wrap each adapter in Code.ensure_loaded?/1). I know the dependency is checked at compile time and always loaded in the library itself, but is there a way to “unload” the dependency during a unit test? I would like to ensure that an error is raised if a user has not added an optional dependency and tries to use its adapter. I have tried using :code.delete and :code.purge with the optional dependencies but that doesn’t seem to work as I thought it would. Maybe I have to delete the files themselves during a test run tagged with :dependency_missing, i.e. mix test –-only dependency_missing? I haven’t been able to find any examples so far about how to do this. Maybe what I’m asking for isn’t practical? Would I have to, say, create separate Mix projects within an umbrella without each optional dependency installed and run the tests I want there? Thanks!
Marked As Solved
dcrck
These are all good suggestions! I’m sure they would all work. What I ended up doing is creating a script that runs once for each optional dependency, i.e. elixir check_optional_dependency.exs dependency_name, in CI. It calls Mix.install/2 to install the dependency, then runs a function to see if the adapter module is available. It also makes sure the adapters for the other optional dependencies throw errors when they are used:
try do
{:ok, _} = adapter.fun(param1, param2)
raise "#{adapter} should not be available!"
rescue
UndefinedFunctionError -> :ok
e -> raise e
end
Also Liked
Asd
If I were you, I’d just not test it, cause it is too much effort for a single and very simple if.
There is no “good” way to test this, only hacks. I love hacks, so I can suggest these two things
-
Use mix_tester. Set up two mix projects. One which installs your dependency (you can specify it as
{:my_library, path: "path/to/my_library"}) andabc. Another one which installs your library, but notabc. Then compile them and run some basic test in them.
This approach is slow, since each test run will installabc, set up mix project and run a couple of binaries (hex usually caches dependencies locally, but still does network lookup to check for source hash changes), but it is the most real-world test you can get -
Use repatch. In the
async: falsetest introduce a global (or maybe shared) patch on theCode.ensure_loaded?/1function to returnfalseforABCargument. Then delete the module and call something likeCode.compile_file(ABCAdapter.module_info()[:compile][:source]), then assert that it fails. Then remove the patch. Then call thecompile_fileagain, to bring the module back
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #hex









