Actions: Assertions

Assertions are the checkpoints of your tests: they verify that the page actually looks and behaves the way it should after your interactions. An interaction that "works" proves nothing by itself — an assertion proves the outcome. You add assertions from the Assert tab of the action picker (⌘K in the visual editor).

Action picker showing the Assert tab with the list of assertion actions — The Add Test Action picker, Assert tab.

Summary

Action	What it checks	Needs a target element
Element is Visible	An element is visible on the page	Yes
Page Contains	The page contains specific text	No
Page Should Not Contain	The page does not contain specific text	No
Element Text Contains	A specific element's text contains a value	Yes
URL Check	The current URL matches an expected URL	No
Email Received	An email arrived at a temp inbox	No

Element is Visible

Checks that an element is visible on the page.

Target: the element to look for, selected in the live preview.

Use it to confirm structural outcomes: the success banner appeared, the modal opened, the "Add to cart" button rendered. Because it matches the element visually, it works even when the text inside changes.

Page Contains

Checks that specific text appears anywhere on the page.

Text: the string to find.

The simplest, most readable assertion: after submitting a form, assert the page contains "Thanks for your order". Prefer text that's unique to the success state — "Submit" probably appears on the failure state too.

Page Should Not Contain

Checks that specific text does not appear on the page.

Text: the string that must be absent.

The negative twin of Page Contains. Use it to catch error leakage: after a successful login, assert the page does not contain "Invalid credentials"; on a production smoke test, assert it doesn't contain "Exception" or "404".

Element Text Contains

Checks that a specific element's text contains a value.

Target: the element to inspect.
Text: the expected substring.

Tighter than Page Contains — use it when the same text could legitimately appear elsewhere. Example: assert the cart badge (not just anywhere on the page) contains "2".

URL Check

Checks that the browser's current URL matches an expected URL.

URL: the expected URL.

Use it to confirm redirects and navigation: after login you land on /dashboard, after checkout you reach /order/confirmation. Pairs well with multi-page flows — see Multi-Step Workflows.

Email Received

Checks that an email arrived at one of your temporary inboxes — optionally containing specific text.

Address: the temp email address to watch (typically the one created earlier in the test).
Content: optional text that must appear in the email body.

This assertion also appears on the Email tab. Use it to verify your app actually sent the welcome email, the receipt, or the password-reset message. Full details and a worked example in Email Testing.

Which assertion should I use?

Verifying an outcome message → Page Contains.
Verifying something didn't go wrong → Page Should Not Contain.
Verifying a specific component updated → Element Text Contains or Element is Visible.
Verifying navigation happened → URL Check.
Verifying email was sent → Email Received.

End every test with an assertion

A test whose last step is a click only proves the click didn't throw an error — not that anything worked. Finish every test with at least one assertion that captures the business outcome: the confirmation text, the new URL, the received email. It's the single highest-leverage habit for meaningful tests — see Test Reliability.