wceolin
Mocking a module called from FLAME.call
I’m using Mox to mock some modules in my app. Usually, it works fine but I have a function that I’m calling inside FLAME.call/2 and it broke my mock:
FLAME.call(Zoonk.FLAME.ImageOptimization, fn ->
Zoonk.Storage.optimize!(key, args["size"] || 500)
end)
After I added it to FLAME.call/2, I started getting the following error:
** (Mox.UnexpectedCallError) no expectation defined for Zoonk.Storage.StorageAPIMock.optimize!/2 in process #PID<0.5593.0> with args ["16.png", 500]
(mox 1.1.0) lib/mox.ex:820: Mox.__dispatch__/4
(zoonk 0.1.0) lib/storage/storage_context.ex:177: Zoonk.Storage.optimize!/2
(flame 0.2.0) lib/flame/runner.ex:431: anonymous fn/3 in FLAME.Runner.remote_call/4
I’ve tried calling Mox.allow/3 in test_helper.ex but it didn’t work:
Mox.allow(Zoonk.Storage.StorageAPIMock, self(), fn ->
GenServer.whereis(Zoonk.FLAME.ImageOptimization)
end)
Any ideas how to make it work inside FLAME.call/2? Thanks!
Most Liked
al2o3cr
Zoonk.FLAME.ImageOptimization is the name of the FLAME.Pool process that manages runners. It receives a :checkout message and returns the actual PID of the runner, which is what you’d need to share the mock with.
al2o3cr
There are three processes involved here:
- the test process, that’s calling
Moxfunctions and the code-under-test - a process running with callbacks defined in the module
FLAME.Pool, namedZoonk.FLAME.ImageOptimization - a runner process, that ultimately tries to call
Zoonk.Storage.optimize!
The Mox.allow you posted in the original post is sharing the mock with the second process, but it’s actually needed in the third.
FLAME.call “checks out” a runner and then sends it work; doing a checkout outside of that will return a different runner process from the pool, so that won’t help.
Your options, IMO, are:
- use Mox globally (with the corresponding loss of concurrency)
- change your architecture slightly: consider wrapping the
FLAME.callin a function and using Mox to replace that. Then, test the code inside theFLAME.callseparately.
Last Post!
wceolin
I see, thanks. I thought there was a way to get the PID of that third process to use with Mox.allow.
I was trying to avoid running tests synchronously. In my initial tests, the runtime doubled from 3s to 6s, but moving those sync tests to a separate module brought it back to 3s. It seems like the best option for now.
Popular in Questions
Other popular topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Move fast and fix things! Error tracking with less noise for Elixir devs who love to ship. Start your free dev account.
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
- #forms
- #api
- #metaprogramming
- #hex
- #security
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 for Elixir devs who love to ship. Start your free account.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"