Assertions that wait

Clicking through a flow proves the buttons exist. Assertions prove the flow actually did something — the order confirmed, the banner disappeared, the URL changed to the dashboard.

What you can assert

Every assertion step has a subtype:

• element — a selector is present in the DOM.
• elementHidden — a selector is gone or hidden (great for "the error banner cleared").
• elementText — an element contains expected text, exact or partial.
• text — the text appears anywhere on the page.
• url — the current URL matches.

Expected values accept the same template variables as inputs, so you can assert on Order #{{orderId}} confirmed and match the value you generated earlier in the run.

Why they retry

The most common false failure in browser tests is asserting a beat too early — right after an SPA route change, before the new view has mounted. Test Chain's assertions retry for about four seconds before giving up, so they wait exactly as long as the UI needs and no longer.

That means no scattering of fixed wait steps to paper over async loads. You assert the result you care about, and the retry loop absorbs the timing. A wait step is still there when you genuinely need a fixed pause — but assertions rarely need one.