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.inspects 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 of my_dep now appears at my_app/_build/test/lib/my_dep
• I make a change to a file in my_app/deps/my_dep, compile the dep with mix 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.