Testing `attach_hook/4` raises ** (KeyError) key :lifecycle not found in: %{__temp__: %{}}`

Phoenix Forum Questions / Help
, ,
1

I wanted to test this server-side hook.

  def on_mount(:default, _params, _session, socket) do
    socket =
      socket
      |> assign(dialog_open: false)
      |> assign(dialog_inner_block: nil)
      |> assign(dialog_history: [])
      |> attach_hook(:dialog_hook, :handle_event, &handle_event/3) # Causes error

    {:cont, socket}
  end

  def handle_event("reset_dialog", _, socket) do
    ...
  end

With this test.

setup %{conn: conn} do
  %{conn: init_test_session(conn, %{})}
end

describe "on_mount: default" do
  test "assigns dialog_open: false", %{conn: conn} do      
    session = get_session(conn)
   
    {:cont, updated_socket} = Dialog.DialogHook.on_mount(:default, %{}, session, %LiveView.Socket{})

    assert updated_socket.assigns.dialog_open == false
  end
end

But I ran into this error.

  1) test on_mount: default assigns dialog_open: false (MyAppWeb.DialogTest)
     test/my_app_web/dialog_test.exs:26
     ** (KeyError) key :lifecycle not found in: %{__temp__: %{}}
     code: {:cont, updated_socket} = Dialog.DialogHook.on_mount(:default, %{}, session, %LiveView.Socket{})
     stacktrace:
       :erlang.map_get(:lifecycle, %{__temp__: %{}})
       (phoenix_live_view 0.19.5) lib/phoenix_live_view/lifecycle.ex:92: Phoenix.LiveView.Lifecycle.lifecycle/2
       (phoenix_live_view 0.19.5) lib/phoenix_live_view/lifecycle.ex:45: Phoenix.LiveView.Lifecycle.attach_hook/4
       (my_app 0.1.0) lib/my_app_web/dialog/dialog_hook.ex:11: MyAppWeb.Dialog.DialogHook.on_mount/4
       test/my_app_web/dialog_test.exs:29: (test)

The socket.private doesn’t contain the key :lifecycle.

%LiveView.Socket{}
|> Map.get(:private)
|> IO.inspect()

=> %{__temp__: %{}}

I have been reading docs and searching around online, but cannot seem to find how to test this scenario.

How would I go about this? Any ideas?

2

I don’t think you can test those callbacks in isolation due to missing simple constructors for that state involved.

Instead I’d suggest creating a full LV module within the test and interact with that one to assert the hooks functionality.

2 Likes
3

Let me see if I understand correctly.

So I create a minimal LiveView and attach to it the hook I want to test?

defmodule SomeMinimalLiveView do
  use MyAppWeb, :live_view
  on_mount {MyAppWeb.Dialog.DialogHook, :default}
  def render(assigns), do: ~H""
end

defmodule MyAppWeb.DialogTest do
  use MyAppWeb.ConnCase
  import Phoenix.LiveViewTest

  describe "on_mount: default" do
    test "assigns dialog_open: false", %{conn: conn} do
      {:ok, lv, _html} = live_isolated(conn, SomeMinimalLiveView, session: %{})
      # make assertions about assigns etc.
    end
  end
end

Would I be able to make assertions about the lv’s assigns directly? Since I see that the lv returned by live_isolated/3 does not carry the assigns.

lv
|> Map.to_list()
|> IO.inspect()

=>
[
  id: "phx-F6vU42JMGscHZQAB",
  module: SomeMinimalLiveView,
  pid: #PID<0.579.0>,
  proxy: {#Reference<0.1239839731.2116812801.228202>, "lv:phx-F6vU42JMGscHZQAB",
   #PID<0.578.0>},
  __struct__: Phoenix.LiveViewTest.View,
  target: nil,
  endpoint: MyAppWeb.Endpoint
]
4

With LiveView tests you can only assert on behaviour, ie, on the outputted HTML. Well, ok, you can use :sys.get_state to look at a process’ state, but I realllllly wouldn’t recommend it.

Harking back to your recent post regarding testing, these are the types of unit tests I don’t bother with. Dialogs are very simple so there is really nothing to be gained from unit testing them in that way. So long as they open, display the correct contents, and all the buttons do what they are supposed to, then the desin of the internal state really doesn’t matter. It also means you could rejig the internals later on without changing the test. That is to say, a LiveViewTest asserting on HTML in a LiveView test is perfectly adequate here. Just my opinion, of course.

1 Like
5

Let’s say someone is stubborn and wants to see how they can test it anyway.

Would this be ridiculous?

defmodule MyAppWeb.DialogTestLV do
  use MyAppWeb, :live_view
  import MyAppWeb.Dialog
  on_mount {MyAppWeb.Dialog.DialogHook, :default}

  def mount(_, %{"dialog_open" => true}, socket) do
    {:ok, assign(socket, dialog_open: true)}
  end

  def mount(_, _, socket), do: {:ok, socket}

  def render(assigns), do: ~H"<.root :if={@dialog_open} {assigns} />"

  def handle_event("set_dialog/3", _, socket) do
    {:noreply,
     set_dialog(
       socket,
       &test_block/1,
       %{test_key: "test_value"}
     )}
  end

  def handle_event("reset/1", _, socket) do
    {:noreply, reset(socket)}
  end

  def test_block(assigns) do
    ~H"""
    <div data-role="dialog-test-block">
      <p><%= @payload.test_key %></p>
    </div>
    """
  end
end

defmodule MyAppWeb.DialogTest do
  use MyAppWeb.ConnCase
  import Phoenix.LiveViewTest
  alias MyAppWeb.{Dialog, DialogTestLV}

  test "dialog closed by default", %{conn: conn} do
    {:ok, _lv, html} = live_isolated(conn, DialogTestLV)
    refute html =~ ~s|data-role="dialog"|
    refute html =~ ~s|data-role="dialog-test-block"|
  end

  describe "Dialog" do
    test "set_dialog/3 renders a dialog with the given inner block", %{conn: conn} do
      {:ok, lv, _html} = live_isolated(conn, DialogTestLV)
      render = render_hook(lv, "set_dialog/3")
      assert render =~ ~s|data-role="dialog"|
      assert render =~ ~s|data-role="dialog-test-block"|
      assert render =~ ~s|<p>test_value</p>|
    end

    test "reset/1 closes an open dialog", %{conn: conn} do
      {:ok, lv, _html} = live_isolated(conn, DialogTestLV, session: %{"dialog_open" => true})
      render = render_hook(lv, "reset/1")
      refute render =~ ~s|data-role="dialog"|
      refute render =~ ~s|data-role="dialog-test-block"|
    end

  # Etc.
  end

Asking for a friend, of course.

6

And I started reading the “Testing Elixir” book. Have good hope I’ll learn some valuable lessons from it. Want to demystify testing…

1 Like
7

:sweat_smile:

For argument’s sake you could do this, yes, but you’re making a little more work for yourself, cluttering up your markup with test-related data, and coupling the test to the implementation.

LiveView tests are UI tests so we generally try and just test how the user interacts with it. A better option would be to set up a LiveView with a button that opens the dialog then you can write tests like this:

# LiveView
def render(assigns) do
  ~H"""
  <button phx-click="open_dialog">Open</button>
  <.root :if={@dialog_open} id="my-dialog">
    I'm the inner text
  </.root>
  """
end

# Test
test "dialog is closed by default", %{conn: conn} do
  {:ok, lv, _html} = live_isolated(conn, Dialog)

  refute render(lv) =~ "I'm the inner text"
end

test "clicking 'open' opens the dialog", %{conn: conn} do
  {:ok, lv, _html} = live_isolated(conn, Dialog)

  lv
  |> element("button", "Open")
  |> render_click()

  assert render(lv) =~ "I'm the inner text"
end

It’s up to your friend, of course! :smiley:

1 Like
8

Maybe it’s my implementation then :thinking:.

The dialog root component is placed in a layout. All the live views that use that layout automatically can use that dialog. The live views will, however, pass the inner block that needs to be rendering inside the dialog dynamically.

So they never do this.

But instead they do.

Dailog.set_dialog(socket, &functional_component/1, payload). The Dialog module exposes all the dialog actions that are possible. There is also Dialog.update_payload/1, for example.

And the live views get events back from the dialog so they can react to an event appropriately according to their needs.

So far it works well, actually. So far.

Definitely learning from the process, so that’s a plus. :upside_down_face:

9

Appreciate all the input!

1 Like
10

Sorry, that was me just not understanding how the dialog is set up so I just made it up, lol. The open button’s click event should be <button phx-click="set_dialog/3">Open</button> and then assert render(lv) =~ "test value". Of course maybe you aren’t using an open button? If not, just set up the LV however it’s going to work in the wild and then you can use all the functions in Phoenix.LiveViewTest to test it just like someone would actually interact with it.

I do wonder why you aren’t using a LiveComponent for this, they are generally very well suited to dialogs! If you use a slot for the open trigger (again, if you even have one) you can keep all the state completely encapsulated in the component. And of course this style of testing makes it really easy to refactor to one.

No prob! I love talking testing. Though as I said in the other thread, I wouldn’t call myself an expert, so maybe I’ll say something stupid enough that it’ll cause someone else to jump in :sweat_smile: I do know a thing or two, though :slight_smile:

1 Like
11

Well… That’s a great question. :sweat_smile:

Back when the dialog was just a baby it seemed unnecessary, but I think it’s time to reconsider :stuck_out_tongue:.

I was originally motivated by this “confirm” component in the LiveBook codebase.

I thought it was such a nice solution. But that was before I started stuffing whole inner_blocks and payloads down the dialog.

1 Like
12

I’ve seen people say they prefer to use hooks. I haven’t studied the livebook example you shared, but in general it can be simpler to use hooks over a component if the LiveView needs to know any state, that way you can avoid having to notify_parent. But if all the state can be encapsulated then I feel a LiveComponent is a little clearer, but honestly both are pretty good, ha. I’m actually still not super comfortable with LiveComponents because I do try and avoid them, but for things like this where there are clear boundaries I use them.

1 Like