Signal Test Environment

For attached components, signal mutations on the test UI thread run dependent effects and bindings before the mutation returns. This applies to value and list signals, computed signals, component bindings, and Signal.effect(). A tester action that changes a signal therefore completes its synchronous UI updates before the next assertion.

For binding APIs, see Component Bindings and Element Bindings.

Mutations off the UI thread queue effects instead of applying them inline. runPendingSignalsTasks() waits up to 100 milliseconds for the first pending task and then drains the queue. It returns true if it processed any tasks. The (long, TimeUnit) overload changes the wait time. Processing the queue is not a guarantee that arbitrary application background work has completed.

The method is also available on JUnit extensions and on each BrowserlessUIContext. When the calling thread holds the window’s session lock, the window API temporarily releases it while waiting so background threads can enqueue tasks.

Changes observed from another session require queued effect processing. Changes made and observed on the same test UI thread propagate synchronously. See Signals Across Windows for context activation requirements.

A shared-signal write applies optimistically: peek() can expose its new value before confirmation. The returned SignalOperation completes after its confirmation task is processed. Result callbacks run in the context that initiated the operation.

Blocking on the operation before draining the queue prevents the confirmation task from running on the blocked test thread. Drain the queue before awaiting or asserting the result.

For a worked example, see Test Signal-Based Views.

For the procedures previously covered here, see the Building Apps guide.

6518E8AD-13F8-48D7-A826-289115FB9A1A