Interactions Reference

Visual Assert

Pass/fail gate that verifies what's described in the question is on screen. The simplest interaction and the one that most determines whether your test catches regressions.

Visual Assert is Mavster's pass/fail gate. You describe what the screen should show; if Mavster can't confirm it, the step fails and the test stops (unless the step has a "run on previous failure" branch).

Phrase your Question to answer as a question — "Do you see the login screen?", "Is a Sign In button visible at the bottom?", "Do you see the 'Saved' success toast?"

Quoting exact text

Wrap any text you want matched exactly in quotes. Mavster will match that literal text instead of interpreting the question loosely.

Single quotes: 'Welcome back'
Double quotes: "Welcome back"
Backticks: `Welcome back` (also accepted; treated as single quotes)
Curly quotes from auto-correct (', ', ", ") work too — Mavster normalizes them.

Examples:

Without quotes	With quotes
`Do you see the welcome headline?`	`Do you see the 'Welcome back' headline?`
`Is the Sign In button visible?`	`Is the 'Sign In' button visible?`

Use quotes when the exact wording matters (button labels, headlines, error messages). Skip quotes for fuzzier checks ("is the cart empty?").

Settings

The Visual Assert editor exposes:

Field	What it does
Question to answer*	A natural-language question about what should be on screen, e.g. 'Do you see the welcome screen?'. Supports $placeholders.
Assert Memory	On by default. When on, Mavster remembers what the assertion target looked like and reuses that memory on later runs (validating before reuse). A 'Clear' button appears once memory has been stored for this step.

When the test's self-healing mode is Per Step, a per-step Self-healing toggle also appears.

Edit Visual Assert Interaction modal: title, Question to answer field with placeholder 'e.g., Do you see the Sign In button?', Assert Memory toggle on, Save and Cancel buttons.

What's possible

Asserting exact text presence: Do you see the headline 'Welcome back'? — quoted text is matched exactly.
Asserting UI element presence: Is there a primary blue 'Sign In' button at the bottom of the screen?
Asserting compound state: Does the cart show 3 items totaling more than $$50? (use $$ for a literal $ — see Parameters).
Asserting state via location hints: Do you see a red error banner near the top of the screen? (no quotes needed — fuzzy interpretation is fine here).

What's not possible

Reading state out of an element to use later in the test — Visual Assert returns pass/fail, not data. Drive variations through $parameters instead.
Asserting on offscreen content — only the visible viewport is checked. Use a Scroll-with-"until" to bring content into view first.
Asserting absence reliably — "the modal is not on screen" is harder than "we're back on the home tab". Prefer positive assertions where you can.

Common patterns

Gate every screen transition with a Visual Assert as the first step after a navigation. Failures localize cleanly to the step that caused them.