gaggle
This post explores different ways to do test automation in Elixir, focusing on how to handle dependency injection — covering patterns, libraries, challenges, and trade-offs along the way. It walks through a series of real attempts using tools like Mock, Mox, ProcessTree, Hammox, and Double, all in the pursuit of fast, simple, and frictionless testing. Part of an ongoing series to explore the “perfect” Elixir setup.
Trending in Blog Posts
Hey folks,
I just published a post about Hologram’s funding and where the project goes next - the short version:
Curiosum as Main Spons...
New
Hey everyone! :waving_hand:
I’ve published Part 7 of the Building Distributed Systems in Elixir series, where we build core distributed ...
New
An educational side project in Elixir, Phoenix, and Tauri. I share what I learned while wiring Automerge into the BEAM, including how I s...
New
So, instead of wasting my afternoon arguing with anonymous handles on X, I turned to my trusty, soulless assistant and said: “Listen, ple...
New
Process labels are useful for visualization and debugging. Here’s why you should use them.
New
New article: Elixir Project Structure — From mix new to a Growing Codebase
I’ve published a new article in my Elixir learning series on d...
New
What happens if you design tools for LLMs instead of letting LLM use human tools ?
Wrote a blog on why and what that enables.
As I see ...
New
Other Trending Topics
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
I am happy to introduce the very α version of the new programming language compiled to BEAM.
Welcome Cure.
It has literally three kille...
New
Hi there! We created Gust: A task orchestrator inspired by Airflow.
For those who have never heard about Aiflow, it’s a Python-based wor...
New
Hi everyone!
The first release candidate for the Expert language server project is now available!
We’ve published a press release detai...
New
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex










First Post!- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
Schultzer
What happen to using behaviours and implement a test module.
I also find that all these libraries makes it way more complex then it should be and forget an important lesson to teach around architecture and simplicity.
I think the Elixir documentation deserves a simple dependency free architecture guide vs a million libraries in search of a problem.
Another point would also be, if you want to mock a HTTP response, why would you not setup a complete web-server for it, so you have a much control as possible, TestServer and Bypass comes to mind, where TestServer really shines with it’s support for WebSockets and flexibility in request patterns that let’s you modal highly complex cases with ease.
Most Liked
D4no0
If you plan on using separate modules, yeah, but generally you have a 2 module setup: the one that calls the external api and the one that does mocks.
Give it a try for sure. This is no new concept and it’s much more easier to reason about compared to the complex setup that mocks require.
Mocking internal logic for me is a hard no, this is one of the big reasons I try to avoid mocks whenever I can. The point of tests is to ensure correctness of your system at different levels. If you are mocking actual business logic, then you are introducing tests that can result in false positives which may cause more problems than they solve, as the code is a dynamic media that is always changing.
Schultzer
Mocking internal code is a huge red flag, it tells everyone that there is fundamental architectural problem, or lack of experience.
In the end, programming is all about data transformations. To put it simple: input → output
So when we test, then we want to assert that we got the expected output from the input.
With that in mind we can design our system in such a way that we only care about changing the input, that input can come from a lot of places.
I saw you mention unit testing and E2E. People tend to conflate all these terms. 99% of the time programmers write integration test, E2E test is a subset of integration test. All your Ecto test are integration test. If a function has side effects then the only way to test it is by an integration test.
Unit test requires a function without side effects.
Regardless of this pedantickery lets just agree that tests should be simple to reason about and if you feel that mocking is the right answer, then you properly have a bigger problem at hand.
LostKobrakai
That approach is also what is presented in this great talk: Boundaries
I personally like this approach quite a lot.
Last Post!
dimitarvp
Apologies if I came off a bit abrasive. I felt the discussion was not going anywhere.
Of course we can civilly agree about the degree of usage of mocks.
But you are quite right that was not the topic. Sorry for derailing. Not going to pursue this (indeed irrelevant to your blog post) angle.