Testing

NSH runs apps headless: the real engine (the same reactive graph, renderer, components, layout and list virtualization as on a device, and QuickJS for TSX), with display frames at 60 Hz, but no simulator, no device and no window. It runs anywhere Cargo or the CLI runs, including Linux CI machines, and does two jobs:

• it runs tests: each opens the app, takes the steps a user would (press, type, scroll), and checks what is on screen. A Rust app’s tests are Rust, run by cargo test with the nsh-testing crate; tests written in TypeScript run with nsh test, for TSX apps and Rust apps alike;
• with --trace, it prints every operation the runtime sends to the native views, with timings: what the first frame, a tap or a frame of scrolling costs.

#Writing tests

The same test, in Rust and in TypeScript: it opens the app with an empty todo list in its storage, types, presses and checks what the screen shows.

// tests/app/main.rs
use nsh_engine::{EngineConfig, Root};
use nsh_testing::{Headless, MemoryStorage};

#[test]
fn adds_a_todo() {
    let mut config = EngineConfig::new(Root::of::<my_app::App>());
    config.storage = Some(MemoryStorage::new([("todos".to_owned(), "[]".to_owned())]));
    let mut app = Headless::start(config).unwrap();
    app.type_text("id:new-todo", "Buy milk").unwrap();
    app.press("text:Add").unwrap();
    app.wait_for("text:Buy milk").unwrap();
    assert!(app.screen().texts().contains(&"1 item left"));
}

// App.test.tsx
import { expect, open, test } from "nsh/test";

test("adds a todo", async () => {
  const app = await open("./App.tsx", { storage: { todos: "[]" } });
  await app.type("id:new-todo", "Buy milk");
  await app.press("text:Add");
  await app.waitFor("text:Buy milk");
  expect(app.texts()).toContain("1 item left");
});

#Tests in Rust with cargo test

A Rust app’s tests are integration tests of its crate, with nsh-engine and nsh-testing (its default features, without QuickJS) as dev-dependencies:

[dev-dependencies]
nsh-engine = "0.1"
nsh-testing = "0.1"

cargo test                    # every test of the crate
cargo test adds_a_todo        # the tests whose name contains "adds_a_todo"

EngineConfig::new(root) is a phone-sized engine (390×844 points) with nothing else set; its fields set what open’s options set below: storage (MemoryStorage::new(entries)), network (StubNetwork, below), viewport, environment (the appearance, the locale, reduced motion), clock (Clock::manual(time), below). nsh_testing::Headless::start(config) starts the app and keeps a model of the views it shows. Its steps are those of nsh test below, with the same selectors, in Rust: press, long_press, clear, type_text, submit, scroll(selector, px(3000.0)), back, wait, wait_for, wait_for_gone, wait_until, run_for, fast_forward, set_system_time, set_viewport, set_clipboard and on_dialog; app.shows(text) and app.screen() (texts(), count(selector), enabled(selector), dialogs(), clipboard(), commands()) read what is on screen. A step returns an error with the texts on screen when it cannot be taken.

nsh_testing::tsx(entry, sets) (feature bundle) opens an app’s TSX entry the same way, built against NSH’s and the crate’s UI sets (Building with Rust). examples/gallery-rs tests its Rust root this way, one module per demo; examples/rust-exports tests its TSX entry from Rust.

nsh test runs these tests too: given the directory of an app with Rust crates (nsh.json "rust"), it runs cargo test for each crate in it before the test files, and shows and counts the Rust tests with the TypeScript ones (✓ src/lib.rs › tests::adds), in its summary and its --junit report. So nsh test is the one command for a Rust app, a TSX app with a crate and a TSX app alike, and nsh check likewise runs cargo check --all-targets on the crates before it type checks the TypeScript.

#Tests with nsh test

A test file is a *.test.tsx or *.test.ts file next to your code. It imports nsh/test, as App.test.tsx above does:

nsh test                      # every test file of the app in the current directory
nsh test App.test.tsx         # one file
nsh test --filter "adds"      # the tests whose name contains "adds"

✓ App.test.tsx › adds a todo (84ms)
✗ App.test.tsx › keeps todos after a restart (312ms)
    expected ["Todos","0 items left"] to contain "1 item left"
    at <anonymous> (App.test.tsx:21:22)
    on screen: "Todos", "0 items left"
error 2 tests: 1 passed, 1 failed (0.9s)

A failing test shows what was thrown, where in the test file, and the texts on screen of the app it opened. Any failure makes nsh test exit with a non-zero code. nsh init creates an App.test.tsx with the app, and nsh check type checks test files with the rest (.nsh/types declares nsh/test).

Each test file runs on an engine of its own, and its tests run one after the other, in order. open starts the app on another engine, a fresh one each time, so tests never share state; the apps a test opened are closed when it ends. A test fails when it throws, when the promise it returns rejects, and after its timeout: 30 seconds, or the milliseconds test’s third argument gives (test("syncs", body, 60_000)). An app with Rust crates of its own (nsh.json "rust") runs its tests in a headless runner NSH builds with them, the same way; in a Rust app (nsh.json "root", Building with Rust), open(".") starts its root component.

#Grouping tests and setting them up

describe, the hooks and the variants of test work as Jest’s:

import { beforeEach, describe, expect, open, test } from "nsh/test";
import type { App } from "nsh/test";

describe("the cart", () => {
  let app: App;
  beforeEach(async () => {
    app = await open("./App.tsx", { storage: { cart: "[]" } });
    await app.press("Cart");
  });

  test("starts empty", () => {
    expect(app.texts()).toContain("No items");
  });

  test.todo("applies a coupon");
});

A hook may be async; its timeout is 30 seconds unless given. Tests and hooks are declared as the file loads: a test declared inside a test or a hook throws.

#Opening the app

open(entry, options?) builds the app at entry (relative to the test file; each entry is built once per run), starts it on a 390×844 viewport and resolves once it rendered and is quiet.

#Playing the host app

An app embedded in a native app talks to it through host. In a test, the test plays the host app: host.params gives the launch parameters the app reads at start, and host.handlers answers the app’s host.call and hears its host.post, by name. A handler is a value, which answers every call, or a function of the call’s data that returns the answer (or a promise of it). What the function throws rejects the call, as a host app’s error does. A call of a name handlers does not list fails, as it does in a host app that handles none.

const app = await open("./App.tsx", {
  host: {
    params: { conversation: "c-42" },
    handlers: {
      "user.profile": async ({ id }) => ({ id, name: "Ada" }),
      "feature.flags": { search: true },
      analytics: null,
    },
  },
});
await app.press("Profile");
expect(app.host.calls()).toEqual([{ name: "user.profile", data: { id: 7 } }]);
expect(app.host.posts()).toEqual([{ name: "analytics", data: { screen: "profile" } }]);
// The app's `host.on("conversation.open", …)` hears it.
await app.host.send("conversation.open", { id: "c-43" });
expect(app.shows("Conversation c-43")).toBe(true);

app.host.send(name, data) sends an event, then waits until the app is quiet. app.host.calls() and app.host.posts() list what the handlers got, in order: name and data.

The URLs the app opens (openUrl, a TextView’s links with links="open") are recorded and reported to the app as opened, and nothing opens on this machine. app.openedUrls() lists them:

await app.press("Contact us");
expect(app.openedUrls()).toEqual(["mailto:help@example.com"]);

#Stubbing the network

network lists routes by "<METHOD> <URL>" (a bare URL is a GET; * matches any text). A request no route matches fails, so tests never reach the network unasked. A route is a response, or a function of the request that returns one (or a promise of one); in Rust, StubNetwork::new(routes) takes the same routes, each a StubResponse or a StubRoute::Handler:

use std::sync::Arc;
use nsh_engine::{EngineConfig, Root};
use nsh_testing::{Headless, StubNetwork, StubResponse};

#[test]
fn adds_a_todo_on_the_server() {
    let mut todos = StubResponse::default();
    todos.status = 200;
    todos.headers = vec![("content-type".to_owned(), "application/json".to_owned())];
    todos.body = br#"[{ "id": 1, "title": "Walk" }]"#.to_vec();
    let mut created = StubResponse::default();
    created.status = 201;
    let mut offline = StubResponse::default();
    offline.error = Some("offline".to_owned());
    let network = Arc::new(StubNetwork::new([
        ("GET https://api.example.com/todos".to_owned(), todos),
        ("POST https://api.example.com/todos".to_owned(), created),
        ("GET https://api.example.com/sync".to_owned(), offline),
    ]));
    let mut config = EngineConfig::new(Root::of::<my_app::App>());
    config.network = Some(network.clone());
    let mut app = Headless::start(config).unwrap();
    app.press("Add").unwrap();
    let methods: Vec<String> = network.requests().iter().map(|r| r.method.clone()).collect();
    assert_eq!(methods, ["GET", "POST"]);
}

const app = await open("./App.tsx", {
  network: {
    "GET https://api.example.com/todos": { body: [{ id: 1, title: "Walk" }] },
    "POST https://api.example.com/todos": (request) => ({ status: 201, body: JSON.parse(request.body!) }),
    "GET https://api.example.com/todos/*": { status: 404 },
    "GET https://api.example.com/sync": { error: "offline" },
    "GET https://api.example.com/slow": { body: "done", delay: 2000 },
  },
});
await app.press("Add");
expect(app.requests().map((r) => r.method)).toEqual(["GET", "POST"]);

A route’s function gets the request (method, url, headers, body as text) and runs in the test file, so it can count requests or answer from what the test set up. A function that throws fails the request and the step that made it. app.requests() lists the requests the app made, in order, the same way.

#Controlling time

On the system’s clock, an app’s timers and native animations take as long as on a device, and so do the tests that wait for them. With a manual clock (EngineConfig::clock in Rust, open’s clock in TypeScript), the app runs on a clock whose time moves only as the test moves it, and at once, as with Jest’s fake timers or Playwright’s page.clock:

use std::time::{Duration, SystemTime};
use nsh_engine::{Clock, EngineConfig, Root};
use nsh_testing::Headless;

#[test]
fn autosaves() {
    let mut config = EngineConfig::new(Root::of::<my_app::App>());
    // 2026-01-01T09:00:00Z
    config.clock = Clock::manual(SystemTime::UNIX_EPOCH + Duration::from_secs(1_767_258_000));
    let mut app = Headless::start(config).unwrap();
    app.type_text("label:Note", "Milk").unwrap();
    app.run_for(Duration::from_secs(10)).unwrap(); // the autosave, ten seconds later
    assert!(app.shows("Saved at 09:00:10"));
}

const app = await open("./App.tsx", { clock: { time: new Date("2026-01-01T09:00:00Z") } });
await app.type("label:Note", "Milk");
await app.clock.runFor(10_000);            // the autosave, ten seconds later
expect(app.texts()).toContain("Saved at 09:00:10");

A StubNetwork whose responses have a delay follows a manual clock with .with_clock(clock.clone()). The steps below are nsh test’s; Headless has each of them (run_for, fast_forward, set_system_time).

Date, performance.now() and Intl’s default date follow the clock. Steps finish what is running without waiting for it: while the app asks for frames or a native animation runs, frames come one after another, each a frame’s time (1/60 s) later on the clock. A 300 ms transition takes a few milliseconds, and a timer due during it runs. app.wait(ms) and a long press move the clock by their time. A timer that comes due later runs only when the test moves the clock there. waitFor’s timeout stays real time, as it also waits for what comes from outside (a route’s function, the network). The gallery’s tests run this way (examples/gallery/tests): its twelve tests that wait for animations take 6 s instead of 28 s.

#Steps

Steps name views with selectors, written as Playwright’s:

label:, text: and a role’s name also take a regex: text:/^Buy/i. >> looks inside what the part before matched (id:cart >> role:button[Remove]), and nth=<n> keeps one of the matches, from 0 (text:Delete >> nth=1). A selector finds the views a user would look at first: in the top modal, then on screen, and of a navigation stack only the top screen. It matches what the user sees: views with an area, outside visibility: hidden, inside the window and the views that clip them (overflow: hidden), or anywhere in the content of a scroll view the user can scroll, which scrolling brings in (opacity and transforms aside, as in Playwright). A step that acts on a view (press, type, clear, submit, scroll, longPress) needs exactly one: a selector matching several fails the step, and the error says how to narrow it.

A step resolves once the app rendered nothing for 100 ms and no native animation runs (2 s at most, for apps that render all the time; on a manual clock, also 2 s of the app’s time), so what it changed is on screen when the next line runs; use waitFor for what comes later (a response, a timer). A step rejects, failing the test, when nothing matches its selector (the error lists the texts on screen), when the app threw an exception meanwhile, and when the app asked for what only a real platform answers.

app.spanStyle("id:guide") reads a nested <Text testID="guide">; text:word reads the first character of that match. Scope queries with id:note >> text:word and select repeated matches with >> nth=0. The query reports an error for a missing, ambiguous or empty span. Updating a span’s testID reuses its text layout and preserves the onTextLayout callback count.

#What headless runs play of the platform

A headless run has the real runtime and no platform. It plays the platform’s part NSH’s protocol defines, and nothing that only a real platform can do:

• Native animations run frame by frame, to their end: start(callback) callbacks run, and so does what waits for them.
• Going back pops screens and closes modals as a platform does (app.back()).
• Dialogs are answered: by the test’s onDialog, else by their cancel button, else they are closed when they can be; a dialog that only its other buttons answer fails the step that showed it until the test says which to press.
• The clipboard holds text: what the app copies, read back when it pastes (clipboard to start with some).
• The page’s host answers host when the app’s nsh.json names one in web.host (The page’s host).
• The app runs under its capabilities: what its nsh.json declares in capabilities is enforced as on a device, so what it does not declare is refused.
• URLs are recorded: what the app opens is reported opened, and app.openedUrls() lists it.
• Picks are answered: with the test’s files (onPick), else cancelled, so Picker.pickImages resolves [].
• Modals show at once: onShow comes when one is presented.
• Images are not loaded: no onLoad or onError comes, and Image.getSize and Image.prefetch reject.
• What only a real platform answers fails the step: an image or files on the clipboard.

#The page’s host

An app published to the web gets its host from its page: nsh.json web.host, a module exporting createHost(player) (Web). Headless runs load that module for each app a test opens, before the app starts, in a JavaScript context of its own (timers and console, nothing of the browser’s, no imports): its call answers the app’s host.call, its player.hostEvent reaches host.on, and host.available() is true. A call that throws, rejects or returns what is not JSON rejects the app’s call with its message, as on the page, and events sent before the app starts reach its top-level listeners once it does. --web-host <module> names another module. The app’s capabilities.host must list what it calls, as on the page. A call’s timeout and the host’s own timers run on the app’s time, so a manual clock moves them (app.clock.runFor). In a browser (--target web) the development page runs nsh.json’s web.host for each app as a published page does; on the other platforms (--target) the apps have no host: host.available() is false.

// nsh.json: { "capabilities": { "host": ["echo"] }, "web": { "host": "./host.js" } }
import { open, test } from "nsh/test";

test("calls reach the page's host", async () => {
  const app = await open("./App.tsx");
  await app.press("label:call");
  await app.waitFor('text:{"n":1}');
});

examples/host-echo has an app, its host and their tests.

#Expectations

expect(value) compares values as JSON does (undefined is null, numbers by value), and each check throws when it does not hold. .not turns them around: expect(app.texts()).not.toContain("Error").

#On a real platform

nsh test --target macos (or linux, windows, gpui, web, ios, android) runs the same tests on the platform’s development host instead of headless: each open starts the app in a window of its own, with a fresh data directory, and the steps act with the platform’s own input at the views their selectors name, as Playwright does in a browser:

• a press is a click at the view’s middle, a long press a held click, type clicks the input and types its keys, scroll is a trackpad gesture over the scroll view, back is what a user does (Escape on macOS and Linux, the mouse’s back button on Windows and in GPUI, the browser’s back button on the web, a sheet swiped down, VoiceOver’s escape gesture while a menu, popover or Sheet is open, else the header’s back button on iOS, the back button on Android);
• a view off screen is scrolled into view first, a gesture at a time;
• selectors, waits and queries see the same model of the app as headless runs, built from what the host draws, so they find the same views;
• dialogs are the platform’s own: app.dialogs() reads them, and answering one (onDialog, or its cancel button when the test says nothing) presses its button;
• app.screenshot(path) takes a picture of the window.

nsh test --target macos                       # the app's tests in macOS windows
nsh test --target linux                       # in GTK windows (xvfb-run -a … on a machine without a display)
nsh test --target windows                     # in Win32 windows
nsh test --target ios                         # in an iOS simulator
nsh test --target android                     # on the Android device or emulator adb lists first
nsh test --target gpui                        # in GPUI windows (macOS, Windows, Linux)
nsh test --target web                         # in a headless Chrome, Edge or Chromium
nsh test tests/form.test.tsx --target macos   # one file

The window opens at the viewport’s size (390 × 844 unless open says), within the screen. A manual clock works as it does headless: app.clock.runFor, fastForward and setSystemTime move the app’s time at once (timers, requestAnimationFrame a frame apart, Date), app.wait(ms) moves it too, and each frame the platform shows moves it a frame (1/60 s), so the app’s time passes while it animates. The platform’s own animations, and a route’s delay, take real time. The app’s requests come to the test as they do headless: network routes answer them, a request no route matches fails, and "live" lets them through to the host’s network; app.requests() lists them all. storage is in the app’s storage when it starts, and app.storage() reads it from the app. locale, reducedMotion and safeArea hold whatever the platform reports, and the app’s clipboard calls are served from the test’s own clipboard (clipboard is its text at first, app.clipboard() reads it), so the machine’s clipboard stays as it was; a text input’s own copy and paste use the system’s. host.params reaches the app, app.host.send sends events, and the URLs the app opens are recorded for app.openedUrls() instead of being opened. host.handlers runs headless: the development host answers no calls, and open rejects handlers there. An app with Rust crates of its own runs in a development host built with its crates, which NSH builds for the platform; a Rust app’s host runs its root, so open(".") starts it there as it does headless.

On the web, the apps run in the development host’s page in a headless Chrome, Edge or Chromium: the one installed on this machine, or the executable --browser <PATH> names (a browser is needed: nsh test says where it looked when it finds none). One browser serves the run, and each open gets a page with storage of its own. The input is the browser’s trusted input, as a user’s: mouse clicks, wheel scrolling and keys.

On iOS, the apps run in the development host in an iOS simulator: the booted one, else the newest iPhone, which nsh test boots. The steps are a finger’s touches and the software keyboard’s typing, as UIKit gets them from the device. setColorScheme switches the simulator’s appearance, which nsh test sets back after the app, and the screen has the simulated device’s size.

On Android, the apps run in the development host on the first device or emulator adb devices lists, with storage of their own. The steps are a finger’s touches and a keyboard’s keys, as the app’s views get them from the device; back is the system’s back. setColorScheme switches the device’s dark theme, which nsh test sets back after the app.

#Steps from standard input

Given the app’s entry instead of tests, nsh test opens the app on the real network, lets it run for 1.2 s, then takes the steps standard input gives, with app the app:

echo 'await app.press("text:+1"); expect(app.texts()).toContain("1");' | nsh test App.tsx

The 1.2 s let the engine’s idle garbage collection run before the first step, so an app that lets go of what it still uses shows it: its handlers stop working.

The examples have tests to start from: examples/gallery-rs for a Rust app (cargo test, one module per demo, and App.test.tsx), examples/rust-exports for an app with a Rust crate, examples/counter and examples/gallery/tests (storage, inputs, a long list, stubbed requests, dark mode, a manual clock) for TSX apps.

#Tracing with —trace

--trace prints every mount batch of the apps the tests open, under the step it came in, and the time of every commit. In Rust, a test prints the same: observe hands it each batch with its step, and EngineConfig::trace logs the perf lines through the log crate (target nsh::perf; install a logger such as env_logger in the test):

let mut config = EngineConfig::new(Root::of::<my_app::App>());
config.trace = true;
let mut app = Headless::start(config).unwrap();
app.observe(|step, batch| nsh_testing::print_batch(&mut std::io::stdout(), step, batch));
app.press("Add").unwrap();

nsh test takes --trace on a test file, or on the app’s entry with the steps on standard input:

nsh test App.test.tsx --trace
nsh test App.tsx --trace                                   # the first frame, then 1.2 s idle
echo 'await app.press("Add")' | nsh test App.tsx --trace    # and a press
echo 'await app.press("Add")' | nsh test App.tsx --trace --target ios   # the same in an iOS simulator

With --target, the trace is the platform’s: the batches the host applied, under the steps that brought them, and the host’s own timings of each commit and event, on the device’s hardware.

Use it to:

• check that an app (or a demo) builds, evaluates and renders without errors;
• see exactly which native views a change creates, moves or updates, and how many;
• measure the cost of the first frame, of a tap and of each scrolling frame;
• catch regressions in CI.

#Reading the output

Here is the counter example with one press (echo 'await app.press("+1")' | nsh test examples/counter/App.tsx --trace), shortened:

✓ bundled App.tsx (3255 B in 6.2 ms)
perf commit: 56 ops, 271µs (list js 5µs), 49 mount items, 21 nodes
perf first frame: eval 187µs, total 820µs
── open(App.tsx): 49 items
   LayoutDirection { rtl: false }
   Create { id: 2, kind: View }
   Create { id: 4, kind: Text }
   Insert { parent: 2, child: 4, before: None }
   ...
   Frame { id: 2, x: 0, y: 0, w: 390, h: 844 }
   Frame { id: 4, x: 24, y: 64, w: 342, h: 34 }
   ...
   Text { id: 4, text: "nsh counter", content: 342x34 @ 0,0 }
   Text { id: 14, text: "0", content: 36x77 @ 0,0 }
perf event Press on view 26
perf event js: 413µs
perf commit: 10 ops, 672µs (list js 7µs), 7 mount items, 24 nodes
── press(+1): 7 items
   Create { id: 42, kind: Text }
   Insert { parent: 32, child: 42, before: None }
   Frame { id: 32, x: 24, y: 366, w: 342, h: 43 }
   Frame { id: 42, x: 0, y: 23, w: 342, h: 20 }
   Text { id: 14, text: "1", content: 36x77 @ 0,0 }
   Text { id: 42, text: "• 1", content: 342x20 @ 0,0 }
   Text { id: 34, text: "Recent values: 1", content: 342x17 @ 0,0 }
✓ App.tsx › steps (1.4s)

#Batches and mount items

Each ── step: N items block is one mount batch, under the step it came in: everything the platform applies to native views for one frame, in one hop to the main thread. The lines in it are mount items:

Only what changed is sent: a tap that changes one number sends one Text item; views get no default style and no empty event mask; unchanged frames are not sent. A frame of scrolling that reveals no new row produces no batch at all.

#The perf lines

Single-run timings depend a lot on the CPU’s clock state (a machine that just woke from idle is slow). Compare runs on the same machine, look at the minimum of several runs, and trust the op and item counts more than the microseconds.

#Scrolling

app.scroll("id:photos", px(3000.0)).unwrap();

echo 'await app.scroll("id:photos", 3000)' | nsh test examples/gallery/Bench.tsx --trace

scroll moves the list 10 points per frame, at 60 frames a second, and each frame’s batch is printed:

perf commit: 55 ops, 1667µs (list js 771µs), 46 mount items, 414 nodes
── scroll(id:photos, 3000): 46 items
   Create { id: 792, kind: View }
   Insert { parent: 94, child: 792, before: None }
   ...

For a list, this shows the virtualization at work: which frames bind new rows, how many operations a row costs, and that frames revealing no new row produce nothing. Use it with a release build (cargo test --release, or ./target/release/nsh in a checkout) for meaningful timings.

#In CI

Headless tests need no device or display, so they run on Linux runners: cargo test for a Rust app’s tests, and nsh test, which needs nothing but the CLI. Any failing test makes either exit with a non-zero code: a test that fails, an app that does not build or renders nothing, an exception the app throws during a step.

# .github/workflows/test.yml
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: cargo test                            # a Rust app's tests
      - run: nsh test --junit test-results.xml     # its TypeScript tests, or a TSX app's

(Install the nsh CLI on the runner the way you install it locally; see Installation.)

--junit <FILE> also writes the results as a JUnit XML report, which CI services (GitHub Actions test reporters, GitLab, Jenkins, Azure Pipelines) show per test: a testsuite per test file, a testcase per test, with what failed, where, and the texts on screen.

To guard performance, record the item counts of a few interactions (the ── … : N items lines and the ops / mount items numbers of --trace) and fail when they grow. Counts are deterministic; timings on shared CI machines are not.

#testID for UI tests

Headless tests check what the runtime renders, and their id: selectors find views by test id. To drive the real native UI with the platform’s test tools (XCUITest, Espresso / UI Automator, Appium, Maestro), give views a test id: .test_id(…) in Rust, testID in TSX:

view()
    .test_id("add-to-cart")
    .p_3()
    .on_press(add)
    .child(text(move || format!("{} items", count.get())).test_id("cart-count"))

<View testID="add-to-cart" onPress={add} style={{ padding: 12 }}>
  <Text testID="cart-count">{`${count()} items`}</Text>
</View>

The test id is a method of every element in Rust, and testID a prop of every element and of every Rust component (Button, Dialog, …). It does not change what screen readers say; use accessibilityLabel for that (see Accessibility). In --trace output it appears in the view’s ViewProps item as test_id: Some("add-to-cart").

#See also

• Performance: what to look for in these numbers
• Dev server and debugging
• Architecture: ops, commits and mount batches