Test fixtures and session helpers for host applications.

Why this ships

Every host was writing the same four helpers, and the hand-rolled login was subtly wrong: it set :user_token but not :live_socket_id, so LiveView's disconnect-on-logout never fired and a session-invalidation test was the only thing that would ever have caught it. That is a worse outcome than duplication, and it is what a shipped helper fixes.

What is deliberately NOT here

No ConnCase, no DataCase, no Ecto.Adapters.SQL.Sandbox calls. Those are bound to your endpoint and your repo, and a copy compiled in the kit's context could not adapt to either. Sandbox ownership stays yours. Everything here is portable: the fixtures go through Auth.register_user/1, which uses the configured repo, and the session helpers only put keys into a conn.

Confirmed vs unconfirmed — read the test, do not memorise a default

user_fixture/1 produces an unconfirmed user, honestly mirroring what register_user/1 does. Confirmation flips authentication behaviour, so a fixture that silently confirmed would leave a reader of

user = user_fixture()

unable to tell why a redirect gate did or did not fire. Ask for confirmed_user_fixture/1 when you mean confirmed.

(confirmed_at == nil after registration is correct, not a defect being papered over: registration_changeset/3 refuses to cast it, confirmation is its own transition, and the gate exists precisely to handle the registered-but-unconfirmed state — so tests have to be able to produce it.)

Usage

defmodule MyAppWeb.AdminTest do
  use MyAppWeb.ConnCase
  import PhoenixKit.Test.Fixtures

  test "an admin reaches the dashboard", %{conn: conn} do
    %{conn: conn} = register_and_log_in_user(%{conn: conn})
    assert conn |> get(~p"/phoenix_kit/admin") |> html_response(200)
  end
end