Skip to main content

​
Start with the cause, not the prose

Every failed step is labelled app, test, unsupported or internal. That label is set where the failure was raised, not guessed afterwards from its wording. It tells you where to look before you read a word of the report.
1

Cause is app

The site misbehaved. Open the failure screenshot and the assertion’s actual value. They are the bug report.Typical: an HTTP 5xx from a navigation, an element that should have disappeared and did not, a control that stayed disabled, a submit that changed nothing on the page.
2

Cause is test

The step does not match the page. The message names what is actually there. Go to the section below that matches it.
3

Cause is unsupported

The check is outside what a browser can observe: an email that was sent, an SMS, a server log. Verify it somewhere else, or use a database assertion if the evidence lands in a table you can read.
4

Cause is internal

Our runner broke, and the report says so rather than blaming your site. Please send us the run id.

​
Common test failures

The message lists what the page does show. Read that first. Usually the target is named differently than you assumed, or the flow never reached that screen.Fixes, in order of preference:
  • Use the wording actually on the page.
  • Name the row for a row-scoped control: “Delete in the Blue Top row”.
  • Use a selector target: #order-total, [data-testid="cart"].
More than one element matches and guessing would be worse than failing. The message lists the candidates.Add an ordinal (“the first product”), name the containing row, or use a selector that matches exactly one element.
Testorim types, waits for the page to re-render, and reads the field back. If what came back is not what was sent, the step fails. A green step on a field that silently cleared is worse than a red one.Usually the app cleared it: a validator, an autosave, an autocomplete that committed something else, or a related toggle re-rendering the form. The warning at the end of a run (“typed value X is no longer present in any visible input”) catches the delayed version of the same thing.
The condition is not in the grammar, and the message lists what is. See Assertion conditions.
disabled, checked, value: and friends are only meaningful on a control. If the target bound to a paragraph, the step refuses rather than reporting the paragraph’s imaginary state as an app defect.Point the target at the control, by name, by control noun, or by selector.
A hidden or absent check needs evidence that the thing was ever there, on this page, and that the page is still alive. When one of those is missing the step fails and names which.Fix: assert the element is visible before the action that removes it. That single extra step gives the absence check its provenance.

​
When the report and your eyes disagree

Trust the screenshot and the actual value. Both are recorded, neither is generated. If a report describes something the screenshot contradicts, that is a bug in Testorim and we want the run id.

​
Warnings worth reading on a passing run

​
Making a flaky test honest

See Reliability. In short: prefer stable targets, set the right auth mode, let the flakiness dashboard tell you which test is drifting, and use retry-on-fail only for genuine animation flake.