Testing a Component Tree

Everything the tree reads from above it: the ancestor-provided values it expects (theme, locale, session), a router, any external store it subscribes to, and a data client. The test wraps the component in those providers before mounting.

A binding is a listener the framework registered on that control for one host event, so writing the element's value property only changes the control and dispatches nothing. The listener never runs, and state keeps the old value.

Mounting attaches a component tree to a host the test owns — usually a container the test created in a simulated document — and returns a root handle. Through it the test queries rendered output, feeds new inputs into the same root, and tears the tree down.

They are two different queues with two different triggers. Advancing the clock fires timer callbacks, and those callbacks only write state; turning a write into committed output is the framework's settle step. Advance, settle, then assert - once per link.

Wrap the tree in a router whose history is an in-memory list rather than the host's address bar, seeded with the URL under test. The test can then assert which route's content rendered, and where a redirect left the location.

The commit event satisfies a lazy binding and a live one alike, so the assertion cannot tell them apart. Only dispatching the per-keystroke event on its own proves state moves while the user is still typing.

A write only queues work. Frameworks batch updates and apply them later, so the host still holds the previous render until the framework's settle step has run — the test must await or invoke that step before asserting.

Immediately after the settle that commits the write starting the async work, and before the clock advances or the work is released. The pending shape exists only in that window; an end-state assertion cannot prove it appeared.

Because the provider stack is near-identical in every test, and hand-wiring it duplicates the application's composition in hundreds of files. Each test still controls its own values: the starting URL, seeded store state, cached entries, collaborator overrides.

Whenever the test wrote that value itself. The text stays on the element unless a render overwrites it, so the read-back passes even if the binding never ran. Assert on output only state can produce.

Give it a scope. Either mount a throwaway host component that calls the unit and exposes its result, or use a harness that opens a reactive scope directly. Updates it produces are settled exactly like a render, and the scope is disposed at the end.

The clock is process-wide state. A test that installs it and never restores it leaves later tests with time frozen, so their debounce, poll and timeout waits never fire - and its leftover callbacks can fire into a torn-down tree.

Because frameworks batch commit work onto different host entry points. A flush drained on the continuation queue is not time-driven and keeps running; work parked on a timer, idle callback or animation frame advances only when the frozen clock moves.

In state created once when a module first loads — a store, cache or client built at module scope. The provider is new each test, but it hands the tree the same long-lived instance.

Because the state is the case's precondition, not its subject. Seeding puts the tree straight into the situation under test, keeps the setup readable and deterministic, and stops every test from depending on the correctness of an unrelated flow.

Go through the framework's own output channel: emit from a stub child, or drive the real child's control so its binding emits. Then assert on what the parent rendered from the payload, not on the emitter being called.

Use the platform's own supply route where one exists, then dispatch the event the binding listens on. Otherwise call the component's payload handler directly with a realistic payload, and say in the test what is left uncovered.

Applying one batch can create another: an effect that runs after commit writes state and queues a second update. So one settle can return with work still pending, and a harness typically loops — settle, check for pending work, settle again — until the tree is quiescent.

Anything downstream of layout and paint. A simulated document models the tree and its APIs but lays nothing out, so measured sizes and positions, overflow, styling-driven visibility, scrolling, hit-testing and real navigation are stubbed or absent — and stubs answer, rather than fail.

Per collaborator, by cost and evidence: run in-process deterministic ones for real, stand in for anything crossing a boundary or a clock. Publish the default, make deviations explicit, revise it when defects escape.

Make mounting the real subtree the default and treat one-level rendering as a named exception. Rendering one level deep never instantiates the children, so nothing they do on mount happens and no composed output exists — the speed is real, the coverage loss is larger.