dcrck
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!
Trending in Questions
Other Trending Topics
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
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex











Showing Posts 1 to 6- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
Asd
Why do you have a specific error in the first place?
Consider you have an optional dependency named
ABCand you have an adapter calledABCAdapter, then you can just doIf your library user writes code like
ABCAdapter.call(...)in their own project, where your library is installed as a dependency, butabcis not installed, there will be no compile-time error, only a runtime one, and this error would be self-descriptive, saying something like “Module ABCAdapter is undefined”. Why do you raise a special error and why do you want to test it?dcrck
What you described is exactly what I’m doing at the moment. In this case I’d want to write this test case in the library:
I’d want to test this because I’d want to make sure that optional dependencies are truly optional, as well as automate this in CI. Maybe it’s not a common use case since I don’t see any other “adapter” pattern libraries that have a test like this.
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 install
abc, 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 getUse 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 backLostKobrakai
You might be able to work with the
--no-optional-depsflag onmix compile. You cannot toggle that out at runtime though. I generally only use that to test for compile time errors and warnings, but running tests might be possible as well.mudasobwa
Introduce the separate env
:ci, exclude this library from it, mark the tests with@tag :ciand runMIX_ENV=ci mix test –-only ci.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 callsMix.install/2to 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: