Nimrod Wandera
Jul 24, 2017 · 1 min read

Hi Lasse Ebert,

Thank you for writing this up. It is a very good survey of the techniques and patterns out there. Very informative.

I have been using the pattern José Valim recommends for a while and found it to be very useful in many cases. However, I found that it falls short when I need to test my application’s interaction with mocked dependency in multiple scenarios. Defining the replacement module only once somewhere outside your tests constrains you to having only the simplest behaviour in that module. Whenever I have tried to make my mocks do more sophisticated things like returning different responses depending on the request, the mock modules just started growing out of hand. And, even if they didn’t grow out of hand, I was always uncomfortable having my tests depend on some unseen module defined somewhere else outside the test.

I realized I needed a very concise way to define mocks that I could use to replace other modules in tests (only by passing them as optional parameters as José recommends). These mocks also needed to be examinable, i.e. I needed a way to ask the mock what calls it received.

To scratch this itch, I created ElixirMock, a small library. I would like to hear your opinion on my approach and API since you have clearly thought about this problem at length.

Thanks.

Nimrod Wandera

Written by

Developer