coladarci

coladarci

Hello, all!

I’m curious if anyone has ideas/experience around the best ways to go about testing live view components. Obviously you can write a test for the live route that loads up the full page, start clicking things, etc, but for a complicated setup with many stateful components, it’s extremely difficult to reach good coverage from testing that high up.

In ember (and I’m sure other front-end frameworks) there are testing practices where you can render a component on its own (the equivalent of an ephemeral live route?) and interact with it asserting along the way that the right things happen. This helps assert strong contracts; i.e what happens if you embed a component with a specific field set to nil; does the component handle it correctly.

Is there are a way to do this? Does this sound like a good path for the framework to go down? A (terrible?) hack would be a /testing scope in the router that is used to just embed a single component on the page and we’d manually add one for each component, but that might give an idea of roughly what we’d want to automate in a testing routine..

Marked As Solved

mcrumm

mcrumm

Phoenix Core Team

With a little bit of setup you can definitely drive a LiveComponent under test without a library.

I will share an example and an explanation of how I got there, but it should be noted that I don’t use LiveComponent very often so this may not meet your every need :slight_smile:

Explanation

A common pattern used in the LiveView tests themselves is to create a LiveView that you can drive under test, for example:

defmodule MyLiveTest do

  use MyApp.ConnCase, async: true
 import Phoenix.LiveViewTest

  defmodule DemoLive do
    use Phoenix.LiveView

    def render(assigns) do
    ~H"""
    <p>the answer: <%= @the_answer %></p>
    """

    def mount(_, _, socket) do
      {:ok, assign(socket, :the_answer, nil)}
    end

    def handle_call({:run, func}, _, socket) when is_function(func, 1) do
      func.(socket)
    end

    ## Test Helpers

    def run(lv, func) do
      GenServer.call(lv.pid, {:run, func})
    end
  end

  test "test assign/3", %{conn: conn} do
    {:ok, lv, _html} = live_isolated(conn, DemoLive)

    DemoLive.run(lv, fn socket ->
      {:reply, :ok, assign(socket, :the_answer, 42)}
    end)

    assert render(lv) =~ "the answer: 42"
  end
end

We can use the run/2 function to execute code on the LiveView process, so it’s capable of doing a lot of heavy lifting.

Note: Adding a run function/callback as in the example above is an anti-pattern for testing real LiveViews. Avoid reaching into the LiveView process state in your tests.

If we pair this with LiveView lifecycle events, we can intercept messages to the LiveView under test as well:

test "intercepts a message", %{conn: conn} do
  {:ok, lv, _html} = live_isolated(conn, DemoLive)

  test_pid = self()

  DemoLive.run(lv, fn socket ->
    socket =
      Phoenix.LiveView.attach_hook(socket, :interceptor, :handle_info, fn
        {:intercept_me, term}, socket ->
          send(test_pid, {:intercepted, term})

          # :halt prevents handle_info/2 from being invoked on the LiveView for this message.
          {:halt, socket}

        _other, socket ->
          # :cont allows handle_info/2 to be invoked on the LiveView for this message.
          {:cont, socket}
      end)

    {:reply, :ok, socket}
  end)

  ref = make_ref()

  send(lv.pid, {:intercept_me, ref})

  assert_receive {:intercepted, ^ref}
end

So if we can construct a custom LiveView that renders a dynamic LiveComponent, then we can drive the isolated LiveComponent under test :slight_smile:

Example

This gist has a complete example: Testing Phoenix.LiveComponent in Isolation · GitHub

The LiveComponentTest support module defined in the gist exposes three functions:

  • live_component_isolated/3 - Starts a LiveView process dedicated to driving the LiveComponent under test. You pass in the conn, the LiveComponent module, and any attributes.

  • live_component_intercept/2 - Attaches a lifecycle hook to the :handle_info stage of the driver process. Use this to intercept messages from the LiveComponent. You can send the results back to the test pid to assert on them. Returns an opaque ref that can be used to remove the intercept if needed.

  • live_component_remove_intercept/1 - Removes a previously added intercept.

Overall, I think this approach provides a lot of flexibility. With some additional work under-the-hood I think instead of intercept it could expose macros like assert_lv_receive, but I will leave that for someone else to explore for now :slight_smile:

I hope that helps!

10
Post #5

Also Liked

mcrumm

mcrumm

Phoenix Core Team

You can use live_isolated/3 to test a LiveView in isolation, but it’s recommended to test through the router (i.e. using the live/2 test helper) as that is required to test live navigation.

Note there is also render_component/3 for testing function and stateful components in isolation.

nicocirio

nicocirio

Hi! Thanks for this great solution! In my case, I also needed to intercept events that were targeted to the parent LiveView (in cases where the LiveComponent does not define phx-target={@myself} for a specific event). Adding the following function to live_component_tests.ex helped me test that behavior:

@doc """
  Intercepts events on the LiveComponentTest LiveView.
  Use this function to intercept events sent by the LiveComponent to the LiveView (when phx-target={@myself} is NOT defined).
  ## Examples
      {:ok, lcd, _html} = LiveComponentTest.live_component_isolated(conn, MyLiveComponent)
      test_pid = self()
      live_component_event_intercept(lv, fn
          "some_event_name" =  event, %{"some" => "example_params"} = params, socket ->
            send(test_pid, {:handle_event_intercepted, event, params})
            {:halt, socket}
          _other, _params, socket ->
            {:cont, socket}
      end)
      assert_received {:handle_event_intercepted, "some_event_name", %{"some" => "example_params"}}
  """
  def live_component_event_intercept(lv, func) when is_function(func) do
    Driver.run(lv, fn socket ->
      name = :"lv_event_intercept_#{System.unique_integer([:positive, :monotonic])}"
      ref = {:event_intercept, lv, name, :handle_event}
      {:reply, ref, Phoenix.LiveView.attach_hook(socket, name, :handle_event, func)}
    end)
  end

Hope this function is helpful for others! :slight_smile:

APB9785

APB9785

Creator of ECSx

Maybe this library could be helpful also?

Last Post!

kamaroly

kamaroly

For those who are still looking for a solution,
I found the following package helpful: Overview — live_isolated_component v0.10.0

Where Next? Top

Trending in Questions Top

katta
I having some trouble figuring out if I have set myself too strict of standards for my production server. Currently I can handle 75% of r...
New
achenet
Hello, I’m trying to build a basic Phoenix web-app, and I’d like to use Tailwind. However, when I launch mix phx.server, I get an error...
New
kpanic
Hi everyone, I am toying with the idea of building a “match maker” for giving personal help to people that wants to start coding. I sta...
New
Cxx-mlr
I’m working on a small exercise involving update_in/3, and I came up with this solution: data = %{ name: "Periodic Table", category:...
New
ChrisAmelia
I’ve got trouble wrapping my head around the order in which functions are called in this snippet (from Phoenix’s authentication): toke...
New
dillonoconnor
Is there any way to avoid the Hologram compiler running when using iex? It seems like the front-end code could potentially be disregarded...
New
thiagogsr
** (ArgumentError) expected :max_attempts to be a positive integer, got: {:@, [line: 10, column: 19], [{:max_attempts, [line: 10, column:...
New

Other Trending Topics Top

GenericJam
Edit: 2026 May 15 - This post is archived. Mob is alive!! Main docs: mob v0.7.11 — Documentation A bit of explanation for the slightly c...
New
mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
budgie
A little off-topic, but I feel like people here have a good head on their shoulders. I used to be quite good at making software. Was luc...
New
KristerV
Hey. Is there anyone here who creates agents in their apps? Not talking about using agents, but creating them. I’m finding it pretty diff...
New
mcass19
ExRatatui lets you cook up rich terminal UIs in Elixir, powered by Rust’s ratatui via Rustler NIFs. Build interactive terminal applicatio...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews