Assertions

The Assert button (main way)#

1. While recording, click Assert, then click an element in the browser.
2. The dialog “Assertion for: <element>” opens. Optionally tick:
   • Not — inverts the check (e.g. “is not visible”).
   • Soft — if the check fails, the test records the failure but keeps running.
3. Pick a check:

For checks that need a value, type it and click Add Assertion (or press Enter); Back (or Esc) returns to the list. The value can contain dynamic data and saved variables — e.g. check that a field equals {{orderId}} saved earlier — and you can change it later directly on the step card.

The same dialog has two more groups, which add steps rather than checks:

• Variables → Save text as variable — saves the element’s visible text (or an input’s value), e.g. an order number, to reuse in later steps (see Variables).
• Interaction → Hover — moves the mouse over the element, for menus and tooltips (see Hover).

Checking a format with a regular expression#

When the exact text changes at every run but its format doesn’t, check the format instead. Tick Regular expression in the Assert dialog, or click the .* button on the step card, and write a pattern — for example ^ORD-\d{5}$ for an order number like ORD-48213.

• Available on toHaveText, toContainText, toHaveValue, toHaveURL and toHaveAttribute.
• An invalid pattern is flagged on the card.
• Saved variables and dynamic values inside a pattern match literally, character for character.

Network assertions#

In Debug → Network, select a request. Under Assertion Actions:

• Status N — adds a step that waits for a response from that address with that status code.
• Endpoint — adds a step that waits for a response whose address contains that path, with the observed status code.

Page health check#

A page health check catches problems a user wouldn’t notice right away. In the Action History, hover the gap between two steps (or below the last one), click + → Page health check. The step checks that, since the start of the test or since the previous health check, there have been:

• Console errors — no JavaScript errors in the console;
• Failed requests — no requests that failed or answered with an error (4xx/5xx);
• Broken images — no images on the page that failed to load.

On the card, choose what to check and what happens when a problem is found: Fail test or Warning only. The list of problems found appears in the Runner output. Manual Steps read, for example, Check page health: no console errors, failed requests or broken images (warning only).

Health checks look at the test’s main page. They are not available in Page Object methods.