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.

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

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.

Isn’t that distinction strictly academical?

I mean OK, I find the following worse:

GithubClient.impl().get_forks(username)

…than this:

GithubClient.get_forks(client, username)

But in the end it’s still a visually noisy abstraction. We shouldn’t need to look at our code and say “this is fine”.

You mean the one above my previous comment where Process.put is utilized? I mean I get it, I’ve used it myself when I really wanted something done and/or it got faster that way (or less visually noisy indeed) but if I can avoid it I’ll absolutely will.

BTW I am really curious if you can offer other patterns for having an implementation vary depending on Mix.env – any others except the two I mentioned? Admittedly I haven’t shopped around for such practices in a long time so might be one of my blind spots.

I think we got them enumerated here: Compile time selection through app env, runtime selection through app env, process dict (+ hierarchy) or plain passed as value and I guess runtime selection through switching out the module itself instead of the module referenced. Each of them come with their own set of tradeoffs.

Personally I think one should choose the option most suitable to when and how implementations need to be switched out. Though I’m not a fan of meck/patch because they hide the fact that there are multiple implementations from the codebase. Looking at the code you expect Module A to be called, but the code in Module A might never be called by tests. I very much prefer explicit polymorphism of implementations.

Also as with all places where polymorphism is involved you want a properly documented interface, so you can test the code using multiple implementations against the abstract interface as well as test that the actual implementations adhere to the interface. Without that I wouldn’t trust myself debugging a failing test a few month down the line and being able to figure out if the code is wrong or the mock implementation is wrong.

Lastly I tend to find that the things I need to mock are often also things I don’t have access to for dev work as well, so I need to be able to work with multiple implementations anyways.

You can have and use a @behaviour even if you don’t use mox. And I agree that when it comes to stuff that’s out of our hands – like 3rd party networked services – then it’s best if we have good contracts, parsing / validation, the whole bag of goodies.

Well OK, it’s hard to disagree on this but how do you cope with the visual noise? Can you give an example with your code? As mentioned above, I find it very non-ergonomic to not just directly call my module with arguments but having to go through a layer of indirection. Would you say you don’t find it as annoying as I do?

That. I tend to put selections behind impl functions in some places, but more recently I tend to prefer passing those implementations around top to bottom. I guess all OTP behaviours work like that as well. You never call MyGenServer.handle_info either and :gen_server just passes around a variable for the module being the behaviour implementation.

Hmmm okay, I can see that, though in the case of GenServer we’re talking about a “live” entity – a separate process – and in our case we’re talking about a “dead” module that has to invoke the network when its functions are called.

But that distinction is likely irrelevant in regards to whether a 3rd party network dependency should accept an implementation as a first argument.

I don’t find the current state of affairs satisfying and I strongly dislike leaky abstractions but I’ll admit that passing an implementation around seems like the least worst way of handling 3rd party network dependencies.

Nothing on the beam runs outside a process though. The question is how much work it is to configure the process and if it’s possible to then pass said configuration down the callstack.

I really like that we can be that explicit in elixir especially over abominations like IoC containers, which you might see in OOP languages. I know it takes effort to add the posibility for switching out an implementation for what was previously a static function call, but imo trying to let it stay a “static function call” when it’s no longer that is even worse.

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.