Fl4m3Ph03n1x
Mocking/Dependency injection in Elixir and Hexagonal Architecture
Background
So, this is the aftermath of reading Mocks and Explicit Contracts and Inversion of Control Containers and the Dependency Injection pattern from Martin Fowler.
Basically, I am trying to cement some ideas and I am looking for a discussion on the topic.
Mocks, are they evil?
Some people say Mocks are a code smell. Now, I stand with J. B. Rainsberger in that Mocks are not evil, they are the canary in the coal mine that is telling you something is about to explode. If you read the full article of Eric Elliot, you will also see he arrives to a somewhat similar conclusion.
Jose Valim seems to agree, and his solution to this issue is to make contracts (interfaces) explicit and never use mock as a verb ( use it as a noun ).
The interface approach to mocks
Now, I will agree that if you have a dependency on the outside horrible world, you should have instead an interface that protects your app and make your app depend on it.
The thing I am not so fond of is on how people seem to use mocks in Elixir. They just have their code call on a contract that has a real mock created and implemented somewhere else, usually a fake object or server with data.
I don’t like this
Call me lazy but I don’t like to create things. I have an aversion to creating false objects. It gives me work and I have to maintain them afterwards.
I much prefer passing the functions that interact to the outside horrible world to my happy zone. Not only that, I usually use the Constructor Injection Form of the Dependency Injection pattern as described by Martin Fowler.
So, if I have a module that needs to interact with the Outside Horrible world, I just pass the functions I need when I am starting it ( or in any other language, instantiating it ).
Valim does seem to agree with this, he mentions that passing functions (Mocks as local) is much easier than having to depend on Full Objects with Interfaces and that depend on the Application ENV. I agree with him.
What’s the issue?
The troubling thing here is that if I pass the test doubles directly via Constructor Injection then I am not applying the Hexagonal Architecture. In J. B. Rainsberger words, I am skipping the DMZ.
Questions
- Am I taking the correct conclusions, as in, do interfaces really allow us to skip the DMZ?
- How do you guys model your apps? Which patterns do you follow?
First Post!
idi527
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:
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)).
Most Liked
peerreynders
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.
peerreynders
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:
Popular in Discussions
Other popular topics
Chat & Discussions>Discussions
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"