That’s imho a big misconception. But there are layers to the problem here:

Currently you’re changing the code executed by having a different config when running tests. This is fine if your tests need a single static setup of dependencies applied.
Now you’re wondering how to move to a place where the single static setup of dependencies is no longer enough for all your tests. One way to do that is changing the setup between sets of tests, which need a common setup.

You’re doing this via the MIX_ENV (could be something else you can check on in a config.exs file) + multiple separated testruns, which is the only way to affect config early enough so you can depend on it at compile time. This is great in terms of your application being statically configured by config and nothing is dynamic at runtime. This also means all the tests you run in one of such batches need to deal with the same setup.

If the above is not flexible enough you need to start setting up dependencies at runtime. And that point is reached earlier than one might expect. E.g. using Mox means you’re setting up a dependency at runtime (the module might be the same, but the functions are different) and you either need to run tests with async: false to have the correct mocked implementation called or you need to pass in something from your test to the callsite, which makes it call the mocked implementation. The same is true for any two concrete implementations you want to change between within the same testrun. If you’re actually using Mox or not is actually not relevant.

So unless you can configure everything statically at compile time you’re in a place where you’re handling multiple interchangeable implementations at runtime and you’re imo better of acknowledging that fact in your codebase instead of trying to ignore it – even if in production there’s only one implementation used.

I’d start with the question: Why do you need another mix env for your integration tests in the first place?
I’m aware that many things differ between unit and integration tests, but if config.exs seems like the only way to provide them you might want to re-evaluate your options on dependency injection.

All of those questions boil down to “how can I make my code do different things (at runtime)”. If you can do that the stubbing/predefined responses part becomes simple, as it’s just one of those “different things” (likely a mox module). To get to that point imagine building a system, where in production you need to be able to switch out those parts, which you want to be able to switch out in your tests. E.g. the code you posted in your first post won’t cut it, as the dependency is set at compile time, so it’s not changeable at runtime.