lessless
I wonder if it’s possible to mimic a simple “class reopening”/inhertinace-based SEAM in Elixir to alter a module’s behaviour without editing its code.
Here is an example in pseudo-Ruby
class PriceCalculator
def calculate_price(order)
base_price = calculate_base_price(order)
shipping = calculate_shipping(order)
base_price + shipping
end
def calculate_shipping(order)
ShippingServices.calculate_shipping(order)
end
end
Now the calculate_shipping is enabling point to override the shipping costs calculation behaviour because we can override it in tests without altering the production code.
class Test
class PriceCalculatorStub < Price calculator
def calculate_shipping(order)
1000
end
end
def test_order_price_is_base_price_plus_shipping_price
assert 1100 == PriceCalculatorStub.new.calculate_price(...)
end
end
Example is adapted from Legacy Seam
Where Next?
Trending in Discussions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Master modern tools, write cleaner code, and tackle real-world challenges with Manning books, videos, and courses. Start building today.
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
- #ai
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #performance
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.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
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!"
First Post!- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
D4no0
If my assumptions are correct, your
calculate_shippingdepends on an external API? If yes, then we universally use mocks for such external calls. There is Mox library that I personally always use and similar ones for doing this.Alternatively, if the things you want to mock in tests are very limited in their scope, you can inject your functions as parameters and later replace them in your tests:
Most Liked
sodapopcan
There’s also Efx. It’s a cool library. Personally I found myself going back to Mox, though (not that that matters).
LostKobrakai
There’s two parts here. There’s introducing the interface of the seam and there’s how to switch out the implementation.
For the first one the answer is quite simple. Extract to a function, make the function inputs and outputs the interface. We commonly use Behaviours for that stuff given things usually don’t just need a single callback.
The latter is dependency injection in whatever form you want to do it. Personally I like explicitly passing in dependencies (e.g.
GenServer.start_link(Dependency, …)is just that), but you can go withApplication.get_envor some other global dependency resolver option. For tests specificallyMoxwill allow you to use a single behaviour implementing module to inject dynamic code to run.I’d strongly suggest not getting hung up on the inheritance portion of this. It’s imo irrelevant to what that blog post tries to teach.
I’d also suggest to let loose of the “without altering the production code”. None of the examples of Martin Fowler left the production code untouched.
LostKobrakai
Imo that kind of thinking is a trap. You by definition now have at least two implementations, not one. It doesn’t matter that only one is used in production.
That’s fair. But I mentioned you don’t need to go the explicitly passing route. You can just as well start some global process somewhere, which provides the dependency to be used. Call that in your code and you don’t need callers of said code to change. Same with
Application.get_env. That’s also global state you can read without needing callers to be involved. The big piece here is “global state” no matter the technical implementation. The technical path chosen by Martin Fowler was global state through a static class variable.Last Post!
yordisprieto