@hubertlepicki what type of setup did you end up with? Are you using Mox in your integration tests? Probably not since Mox is more for unit testing.

A better question is how are you setting up the mocks so that you can use the mocks for unit testing but not use them for integration testing.

We went with full stack testing from our UI app. So we prepare database, open browser, it clicks around and does hit the database.

We did get with using Mox to test core app.

Right, so you most likely have an umbrella app. Umbrella apps share the configuration, so you end up with precisely the above problem.

Our app is just a folder with 3 apps now, and we require the core from ui as a dep (with path: "../core") in mix.exs, and do similar with core and db apps.

This allows us to have different configuration for test env: in core we use Mox, but in ui we don’t.

In a nutshell, we treat the other apps as if they were library dependencies. So we do have some duplication in configs, i.e. config for ui configures all 3 apps, config for core configures core and db etc.

There is a nice advantage of that: you test the db app in isolation from rest of the system, the core app is not aware at all about existence of ui. Nice bounded contexts

Yeah we are using an umbrella app which is part of why it is difficult to test the dependencies between the different apps. Maybe we should start looking at moving away from it.

I prefer to have each application as its own ‘library’ which I then include into an overall meta-application that does nothing but set up the links between the other applications. Something like having one application access another can be done by just passing the name as a config option, this also makes it really easy to test as you can essentially ‘mock’ the connection by just passing a different module into the config too.