LiveView isolated Component Tests?

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

I wish the LiveComponentTest was included out of the box in Phoenix. It looks like what I have been looking for.

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!

The live_isolated_component is exactly what I wanted!

The caveat is that I’m just starting to look at LiveView, but this seems like a big missing piece unless I’m doing something wildly wrong (which is possible I admit): I am using assign_async to do some data loading in a component and there’s not an obvious way to test that in isolation of a view. render_async only works with views and so won’t work with the seemingly only way to test a component which is render_component. That’s a pretty big limitation and I would expect something like live_isolated_component to be included in the library.

Thanks for pointing that out.

Thanks for this - I can confirm live_isolated_component does the trick and works great for this use case!

Just want to followup here and say this is working quite nicely for us. The only thing that is a bit difficult is debugging with open_browser/1 since it’s not rendering the root template; we lose the styling. Is there an easy way in your mind to change

    def render(assigns) do
      ~H"""
      <.live_component :if={@lc_module} module={@lc_module} {@lc_attrs} />
      """
    end

in the driver to render this inside the root template?

Ah, it was the default attrs on the macro. I updated the gist to use an empty list instead of nil and that seems to have resolved it. Thanks for pointing that out!

UPDATE: I got it but leaving here for posterity. Just some confusing meta programing warnings that go away when I completed the test that uses live_component_intercept.. Thanks, again!

As an FYI, the code you provided seems to work great locally, though the macro is throwing a warning on this line: Testing Phoenix.LiveComponent in Isolation · GitHub

warning: this check/guard will always yield the same result

I’m having a hard time figuring out why but will keep digging!

Just want to thank you for this extremely thorough response and example - this is exceptional. In my experience outside of live view, this is the way to think about testing a complicated live view app; your components are like functions and you want to write them to be easily testable in isolation to cover all the edge cases they have to handle. It’s wonderful to know it’s possible, and with your macros, straight-forward

Once again, appreciate all you do!

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

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

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

I hope that helps!