So the issue here is that mox doesn’t use your implementation in lib/configuration.ex. All of the callbacks your behaviour has are expected to be different for your mock and must therefore either be expected to be called or at least stubbed with the functionality mox provides. The mock does not inherit functionality from anywhere it just know’s the contract it needs to apply to.
I hope you’re already aware of the reasons for using behaviours as requirement in mox (if not just ask), but behaviours are the written contract about what different implementing modules need to provide as functions so the system using those modules does work. So think less of it as “switching out a function, which is currently inconvenient”, but more like “switching out one piece of stand-alone functionality for another”. Behaviours make sense for e.g. gen_servers, where boilerplate functionality is provided by otp, but the details are supplied by the user. It also makes sense when using an adapter pattern like in ecto switching out databases or in bamboo/swoosh switching out email providers.
For your paths functionality I’m really wondering if you really need a behaviour (and therefore mock) in there or if your implementation is not flexible enough to get those paths (optionally) passed from a higher level entrypoint, so you can simply pass different values from your test.
