You cannot work yourself out of the limitations of meck/patch. They’re replacing modules within the beam runtime wholesale to implement their behaviour, which by definition means you cannot use them with concurrent tests.

It’s interesting how dividing this can be. A mock is going to be another implementation and making this a behaviour instead of trying to ignore it will make things more obvious imo. Having a proper interface should also make it clear how each end of the interface is meant to be covered by tests.

There’s also no need to configure things at compile time. Mox doesn’t care how you switch out implementations, only that you do so. E.g. see the mentioned blog post around ProcessTree, where you could pass implementations in with the process start arguments.

I basically don’t see it. My regular code just calls (as an example) FlightTracker.get_flights(tracking_number). That module both defines the behavior but also does

def get_flights(number) do
  impl().get_flights(number)
end

So there is one basically boilerplate module that wraps it all and then the rest of my code doesn’t care. For that, I get async tests, a dev implementation that has to be different than prod anyway due to API limits, and all the caller code is still perfectly clear.

Yep, with e.g. mox to have contracts and then have dual implementation. I personally dislike that, too much writing and the result somehow does not impress because you also have to have compile-time configuration for test and non-test environments to pick an implementation. To me it’s an expensive abstraction.

I prefer mock or patch these days. They are much more transparent and stay out of your way.

Mmmm, don’t. No point. If you are going to do that then you might as well use mox because it’s almost the same. Though with mox you still keep the two implementations around… but with compilation paths that are different per environment – a standard practice in Elixir, and even newly generated projects have that feature, check elixirc_paths in mix.exs).

So I day don’t.

Maybe bypass? I am not impressed by it but many colleagues prefer it, arguing that it’s better to have a half HTTP server than to have none and just mock responses. Huge debate that we best not get into but I thought it’s best to give you another perspective.

My personal preference was mock, also used patch once and liked it. They are interchangeable.

Though have in mind the following, taken from patch README:

Since the global execution environment is altered by Patch, Patch is not compatible with async: true.

Same applies for mock.

mox allows for async tests.

On a technical level this is indeed different, but on a functional level you have the interface in the form of an http api specification. Instead of switching out a module you’ll be switching out an endpoint. The only downside I see to this is that while you have an interface you’re not in control over the interface. The provider of the http api changing requirements breaks not just the integration with the actual API, but also all the rest of the codebase depending on the interface. If you wrap things in your own abstraction you can limit that blast radius.

This might also be a small push to define the interface by what the application needs rather than what the (current) provider provides.

module PaymentServer.Exchange.MockAlphaVantageApi is not available. This part of the error message is the key. It’s trying to call the correct module, but it’s not available. So the question would be where you put the module definition.

Not yet tinkered with the combination but this might fit: async: false is the worst. Here’s how to never need it again.