Mocking a module called from FLAME.call

wceolin

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!

4 comments

/phoenix #mox #flame

0 413 4

2024-07-24 06:17:44 UTC

Showing Posts 1 to 4

Show Best Posts
Show All (oldest first)
Show All (newest first)

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.

Post #1

wceolin

Thanks for the pointer but I’m not sure I understood it (sorry, I’m very new to Elixir). It looks like:

FLAME.Pool is the process that manages runners. That’s the process I need.
It receives :checkout messages that returns the PID I need.
The code you linked suggests this is happening on the checkout_runner function, which is called on the handle_call callback.

Do I need to listen to a callback somewhere? Doing some GPT-driven research, it suggests I need to call GenServer.call(:flame_pool, :checkout) but that doesn’t seem to return the correct PID. GPT isn’t very good with Elixir, unfortunately.

I know I can probably use set_mox_global (that seems to be what the FLAME codebase is using) but I’d love to understand how this actually works because I feel a bit lost here.

Post #2

al2o3cr

There are three processes involved here:

the test process, that’s calling Mox functions and the code-under-test
a process running with callbacks defined in the module FLAME.Pool, named Zoonk.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.call in a function and using Mox to replace that. Then, test the code inside the FLAME.call separately.

Post #3

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.

Post #4

— All posts loaded —