Mob.ScreenCase: blessed in-BEAM screen testing (+ contract check, device backend)

[GenericJam]

What

Mob.ScreenCase — the blessed way to unit-test a Mob.Screen in the BEAM, no device or emulator required. The screen-level analog of Phoenix.LiveViewTest, but better positioned because render/1 returns a typed view tree (%{type:, props:, children:}), so assertions are tree queries against real data instead of brittle HTML-string matching.

defmodule MyApp.CounterScreenTest do
  use Mob.ScreenCase, async: true

  test "increment bumps state, text, and stays renderable" do
    view = mount_screen(MyApp.CounterScreen) |> render_event("increment")
    assert assigns(view).count == 1
    assert text(view) =~ "Count: 1"
    assert find(view, :button, tag: "increment")
    assert_renderable(view)
  end
end

The three tiers

• Tier 1 (drive in-BEAM): mount_screen/3, render_event/3, render_info/2, assigns/1, plus tree queries (tree, find, find_all, text, flatten) whose vocabulary mirrors Mob.Test (the device driver).
• Tier 2 (contract check): assert_renderable/2 verifies every node type is renderable, derived at compile time from priv/tags/{ios,android}.txt (the same authoritative source the ~MOB sigil validates against) plus :native_view, with an :extra opt for plugin/custom types. Catches "emitted a node the native layer can't draw" at mix test time.
• Bridge to Tier 3 (device): the View carries a :source (:beam | :device). device_view/1 wraps a running node; tree/1, assigns/1, navigated_to/1 dispatch to Mob.Test over Erlang-distribution RPC. The query + assertion layer is tree-based, so the same assertions run in-BEAM or against hardware; only driving differs. Device examples are @tag :on_device (already auto-excluded).

Plus navigated_to/1: in-BEAM it reads the nav action Mob.Socket.push_screen/3 records; on device it returns the live screen.

It also starts Mob.State per test against a throwaway data dir (like ConnCase starts the Ecto sandbox), since screens commonly read it in mount/3.

Tests

18 pass, 1 excluded (the device example). credo --strict clean. Companion mob_new PR scaffolds one of these from mix mob.new.

Caveat

The device backend reuses the existing, working Mob.Test RPC surface and compiles, but the on-hardware run hasn't been exercised in CI (no connected node). The in-BEAM tiers are fully verified.

🤖 Generated with Claude Code