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…
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.
This is very helpful - so @mcrumm it sounds like render_component is what I want except that it only renders it; it doesn’t let you interact with it and test the result. @APB9785 's link to live_isolated appears to do what I’m after - is there no way to do that w/out a library at this point, to know your knowledge?
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
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
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
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!
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!
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?
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.
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
