Background

I have an umbrella application that has several apps inside. These apps communicate and depend on each other.

So, when I am testing, because I am using mocks, I need to mock their interfaces. Now if you know about mocks or if you have read Jose Valim’s opinion on them (Mocks and explicit contracts « Plataformatec Blog) you know this brings an issue:

• Using Mocks means I can deviate from the real implementation.

App Structure

Imagine I have an umbrella project with 2 apps:

• cli (a command line interface)
• manager (where all the logic is)

Umbrella Project structure

.
├── README.md
├── apps
│   ├── cli
│   └── manager
├── config
│   └── config.exs
├── mix.exs
└── mix.lock

Now, every time I change the manager’s Public API, I have to update the interface on cli, otherwise my tests in cli will pass even though nothing will then work:

cli app stucture

.
├── README.md
├── lib
│   ├── cli.ex
│   └── manager.ex # interface for the manager umbrella app
├── mix.exs
└── test
    ├── cli_test.exs
    ├── support
    └── test_helper.exs

Problems

So, following this pattern, I have a few issues:

• every time create a new @type in the manager, I have to update all the interfaces that use it, so the projects using manager as a dependency can have access to the new types I created.
• every time I change manager’s public API, I have to update the projects that use it as a dependency
• I have a manager.ex file in my cli app, that is just an interface for the manager app. This is confusing, as people reading my code will not intuitively understand this is just an interface so i can create a mock that obeys it (mocks as nouns :D)

Possible solutions?

Given these issues I have considered the following option:

• create a new app, called interfaces, where I define the interfaces of all umbrella apps.

This would have the following benefits:

• Changes to the Public API of any app would always be reflected there.
• All dialyzer @types would be there as well
• Any project using the Interface app as a dependency would have immediate access to the most updated interfaces and type specs.
• I would get rid of the manager.ex file because I would import it from the interface app

It would however have the following drawbacks:

• Any umbrella app would be forced to have 2 dependencies: the interface app, and the app they want to use (in this case, cli would have to import both interface and manager)
• They would have access to all interfaces and type specs, even if not needed
• I would still have to change things in two places: the interface app, and the app that implements the interface.

So I am not really sure on how to deal with this issue.

How do you guys deal with this?