Using Wallaby and Mox with some nested LiveViews

thedelchop

Hello,

I’ve been using Wallaby lately and its been fantastic, so big thanks to the entire Wallaby team. In order to mock some 3rd party calls, I followed their docs and setup my own sandbox, so that, as I understand it, when I mock processes in the owner process (the test), those mocks can be shared with the child process (the actual live view process under test), and so far that has worked great.

Here’s a link to those docs, and my setup is identical to the example here with my own specific mocks substituted:

# config/support/sandbox.ex

defmodule YourApp.Sandbox do
  def allow(repo, owner_pid, child_pid) do
    # Delegate to the Ecto sandbox
    Ecto.Adapters.SQL.Sandbox.allow(repo, owner_pid, child_pid)

    # Add custom process-sharing configuration
    Mox.allow(MyMock, owner_pid, child_pid)
  end
end

However, I’ve recently nested a Live View within one of my live views, using live_render, and that breaks some of my tests. I am fairly confident that this is because the nested live view process hasn’t explicitly been granted access to the mock like the parent live view process has been.

I’m wondering if its possible to correct this issue without resorting to globally available mox, but sadly I don’t think so, because if I understand this correctly, when the Sandbox code is executed the child processes don’t even exist as of yet, so I have no pid which to allow.

Does anyone have any other strategies to handle this kind of problem, or is the best bet just running the test synchronously so that I can make the mock I define globally available.

2 comments

/phoenix #wallaby #testing #liveview

2 1395 2

2024-10-21 07:01:28 UTC

Showing Posts 1 to 2

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

Neophen

Did you have any luck fixing this?

Post #1

jack456jokky

thedelchop:

I’ve been using Wallaby lately and its been fantastic, so big thanks to the entire Wallaby team. In order to mock some 3rd party calls, I followed their docs and setup my own sandbox, so that, as I understand it, when I mock processes in the owner process (the test), those mocks can be shared with the child process (the actual live view process under test), and so far that has worked great.

Here’s a link to those docs, and my setup is identical to the example here with my own specific mocks substituted:
# config/support/sandbox.ex

defmodule YourApp.Sandbox do
  def allow(repo, owner_pid, child_pid) do
    # Delegate to the Ecto sandbox
    Ecto.Adapters.SQL.Sandbox.allow(repo, owner_pid, child_pid)

    # Add custom process-sharing configuration
    Mox.allow(MyMock, owner_pid, child_pid)
  end
end
However, I’ve recently nested a Live View within one of my live views, using live_render, and that breaks some of my tests. I am fairly confident that this is because the nested live view process hasn’t explicitly been granted access to the mock like the parent live view process has been.

I’m wondering if its possible to correct this issue without resorting to globally available mox, but sadly I don’t think so, because if I understand this correctly, when the Sandbox code is executed the child processes don’t even exist as of yet, so I have no pid which to allow.

Does anyone have any other strategies to handle this kind of problem, or is the best bet just running the test synchronously so that I can make the mock I define globally available.

Hello,

It’s great to hear it’s been working well for you. You’re right about the nesting of Live Views complicating the mock sharing. One approach you might consider is using a dynamic approach to grant permissions to nested Live Views.

You could leverage a :supervisor to manage the child processes and dynamically allow access to mocks during their initialization. This way, when you render the nested Live View, it can request access to the mocks from the parent’s context.

Alternatively, if it’s feasible, running your tests synchronously to ensure the mocks are globally accessible might simplify things. I’d be curious to hear how others are handling similar issues, especially with maintaining clean tests without relying on global mocks!

Post #2

— All posts loaded —