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!