How do you manage umbrella apps with inner dependencies?

Doesn’t :cli have {:manager, in_umbrella: true}? Then :cli can use anything (public) in :manager.

yes, it does. But I still have to create a manager.ex file that is an interface so I can use Mox.
And when you say public, you also mean @types ?

I guess we already had this conversation, but I personally would not mock internal dependencies in the first place. But manager.ex is one file in :cli, which belongs to :cli and is built to its needs. What exactly would you be copying from :manager and why?

manager.ex is a behaviour, that represents the public API of the manager app.
The manager app is an implementation of the manager.ex behaviour.

I have this behaviour so I can mock its implementation with Mox.

How would you solve this without mocks? Inject the dependencies directly?
You would end up with the same issue in the end, in the sense that a change in manager would always require another in cli.

I have a feeling this discussion comes up often in different ways because I have not yet cemented a solution Or perhaps this is something more general and I am not seeing the full picture.

So either :cli depends on :manager and takes what it gets or :manager depends on :cli and implements the interface :cli prescribes. If you do both you’re in trouble. You don’t want circular dependencies.

Also what you’re seeing here is partly the cost of decoupling things, just that you’re not yet seeing any benefits out of that, because you’re only doing it for mocking and not for general decoupled parts in your system.

So, a few questions:

1. What do you think about the interface app idea? Overkill?
2. Since you wouldn’t use mocks, would you inject dependencies directly? What would you do exactly?

This discussion is making me realize that perhaps the behaviour should be in the manager app instead of the cli app.

Good discussion!

If there’s no need on the manager side I’d test :cli by letting it call into :manager directly. No need to switch implementations without good reason. I also wouldn’t opt for an “interface” app yet. If you actually decouple those apps at some point (no hardcoded dependencies anymore) a shared interface might make sense.

Those apps are decoupled because my manager can have different types of interfaces. cli is just one of them, I will eventually add a phoenix-live interface that talks to the manager.

This is way decoupling was something I did in this small project.

If I allow cli to call manager directly, then I will be doing end to end tests only, that is not my objective. Or perhaps I miss understood you?

Yeah, but :cli doesn’t need to be able to interact with multiple backends I imagine. :manager is the only one it interacts with. So no decouling in that direction.

So what? To me this is not a problem in itself. If there’s something in manager, which makes testing hard, this might change. But for that fact of the part making it hard, not because I want to not have end to end tests.

Don’t know if it helps, but here are my 2 cents how we solve it.

We have the following umbrella structure:

.
├── apps
│   ├── api_client
│   └── app

api_client exposes this function ApiClient.Companies.list
app uses the api_client app as a dependency (in_umbrella: true).
Now let’s say we are writing tests for app that do something with what ApiClient.Companies.list returns. First we create a wrapper for ApiClient inside the app. So we never call ApiClient.Companies.list outside of this wrapper directly. This is also where we introduce a new behaviour and use Mox to create a mock for it.