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

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.

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
]

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.

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.

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

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!

Maybe it’s my implementation then .

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.

Appreciate all the input!

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 I do know a thing or two, though

Well… That’s a great question.

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

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

https://github.com/livebook-dev/livebook/blob/main/lib/livebook_web/components/confirm.ex

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