Hi, I’m the creator of LiveVue library heavily inspired by LiveSvelte.

I can add 2cents from my side, there are two valid approaches to testing:

1. Easier, test rendered props passed to svelte component
2. Harder, proper end to end tests with Wallaby etc.

Approach 2 is kinda obvious, and gives you the most value but with significant initial investment.

But, I wanted to explain a bit more about 1). In LiveSvelte props are rendered simply in data-props attribute of a LiveSvelte root element. So it should be fairly trivial to decode them. Something along the lines (extracted from LiveVue version):

def get_svelte(html, opts) when is_binary(html) do
    if Code.ensure_loaded?(Floki) do
      svelte =
        html
        |> Floki.parse_document!()
        |> Floki.find("[phx-hook='SvelteHook']")
        # TODO - handle cases when there are more than 1 component
        |> List.first()

      %{
        props: Jason.decode!(attr(svelte, "data-props")),
        component: attr(svelte, "data-name"),
        id: attr(svelte, "id"),
        ssr: attr(svelte, "data-ssr") |> String.to_existing_atom(),
        class: attr(svelte, "class")
      }
    else
      raise "Floki is not installed. Add {:floki, \">= 0.30.0\", only: :test} to your dependencies"
    end
  end

Then, you can make assertions on these props, in the same way as you’d be testing a normal LiveView application.

test "test render", %{conn: conn} do
    {:ok, view, html} = live(conn, "/")
    %{props: props} = get_svelte(html)
    assert props["statement"] == "I love Svelte and Vue"

    html = render_hook(view, "randomize", %{}) 
    %{props: props} = get_svelte(html)
    assert props["statement"] == "I love Elixir"
end

This simple approach let’s you test all the updates inside the Live process, and check if rendered props are what you’d expect. Obviously it’s not checking actual rendered HTML, event handlers etc, but often it’s a good tradeoff.

Maybe @woutdp would be willing to incorporate such a helper inside LiveSvelte as well?

Thanks for the comment, but I expect the testing to just test the actual html and handlers. Tying tests to framemork attributes is a so-so idea in my opinion