Mocking/Dependency injection in Elixir and Hexagonal Architecture

Not sure if it applies, but I rarely have a need for mocks – I just try my hardest to keep everything pure. And when I do need to get dirty (usually at the edges of the system, like interaction with some external api), I only have to write a few (integration?) tests to exercise the “protocol”.

I started following this approach in elixir after first applying these ideas in swift:

• Reducers
• Statements, messages and reducers

But I mostly use message passing / plug’s conn-like (or ecto’s changeset) structs instead of reducers in elixir. The big downside of this approach when used with message passing is that messages in erlang are untyped, so i can never be really sure that the program works as expected (unlike in swift, rust, or pony (where messages are typed)).

As do I, but if your entire application is pure, then it is also entirely useless

Side effects are the bane of all programmers, but they are also a necessary evil we must deal with. That’s why these types of discussions exist

Am I taking the correct conclusions, as in, do interfaces really allow us to skip the DMZ?

I’m not sure I’m understanding what you are trying to imply. For the moment lets stay in Rainsberger’s Java world. My interpretation is

• Happy Zone (HZ) gets to specify the interface that it needs to interact with the Horrible Outside World (HOW)
• DMZ has to adhere to the HZ interface but is responsible for the implementation and ultimately interaction with the HOW. All interactions with the HOW are restricted to the DMZ.
• Therefore any functions (e.g. your passed constructors) that directly interact with the HOW or are used by the HOW are to be quarantined inside the DMZ and are off limits for the HZ. Everything living in the DMZ will ultimately require an equivalent mock for the purpose for testing.
• Those mocks are those false objects you don’t like creating - therefore you are not in alignment with Rainsberger’s vision.

I was actually afraid of this. I still have some trouble with Rainsberger’s vision. He mentions “test doubles”, not mocks or anything in specific. If I pass a stub ( instead of a mock ) to a function, am I still not adhering to his vision?

From the Java world where ( up until last year IIRC ) you couldn’t pass lambdas the only solution was to create Mocks. But in Elixir, JS and many other languages where functions are first class citizens, do we really need mocks at all?

Really wish I could talk about this with someone.
I think the thing I miss the most is a good example … but that is a topic for another post.

If I pass a stub ( instead of a mock ) to a function, am I still not adhering to his vision?

Ok, I need to watch my terminology - what I should have said:

Those doubles are those false objects you don’t like creating.

Gerard Meszaros actually breaks test doubles down in xUnit Test Patterns: Refactoring Test Code (p.133):

So there is nothing wrong with using any sort of “test double”, including a stub.

From the Java world where ( up until last year IIRC ) you couldn’t pass lambdas the only solution was to create Mocks.

You have been able to use anonymous classes (a misnomer really, as it’s essentially a classless object) for a long time as ad hoc implementations of interfaces - which is really what you needed as you had to satisfy the entire interface for the sake of static typing.

do we really need mocks at all?

No. You mentioned Detroit-school vs. London-school - Martin Fowler actually uses the terms Classical vs. Mockist Testing. Classical testing existed before mocks emerged and made due with dummies, stubs, and fakes.

But the issue seems to be that you have been operating in the mockist tradition and acquired a distaste for expending effort on implementing dummies, stubs, and fakes.

With regards to the mockist approach even Martin Fowler comments: