When I’m working on a mix app, I’ve noticed that changes that I make to code in my app’s dependencies are observable in the dev
environment after recompiling the dep, but not in the test
environment. Is this an intentional part of mix’s design? If so, is there a mix-based workaround?
Here’s an example scenario… I’m working on an app, doing some basic red-to-green testing. I’m having trouble debugging my app’s integration with one of its dependencies, and want to throw some IO.inspect
s into the dep to help me debug. I add the debug code, recompile the dependency, and run the tests again, but the code I’ve added has no effect. However, if I remove the directory at _build/test/lib/my_dep
and run the tests again, the changes are present.
Steps to replicate:
- get a dependency with
mix deps.get my_dep
- compile the dependency with
mix deps.compile my_dep
At this point, a compiled version of the dependency will appear at my_app/_build/dev/lib/my_dep
, but not at my_app/_build/test/lib/my_dep
- I run tests with
mix test
- the compiled version ofmy_dep
now appears atmy_app/_build/test/lib/my_dep
- I make a change to a file in
my_app/deps/my_dep
, compile the dep withmix deps.compile my_dep
, and run the tests again
The change that I’ve made to the dependency is reflected in the _build/dev/
version, but not in the _build/test/
version - so if I run the tests again, the change does not take affect, nor is it observable if I start an iex session via MIX_ENV=test iex -S mix
(though it is observable if I start iex in the dev
environment).
From walking through this step-by-step, it’s become evident to me that deps are compiled differently for different environments . If there’s no other way around this, it’s not a big deal - I just have to run $ rm -rf _build/test/lib/my_dep
when I make changes… but I’m interested in learning more about this aspect of mix’s design, and if there’s a way that I can recompile a dependency specifically for the test environment.