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 count that came back wrong.A text or value mismatch on an element that was found is marked unconfirmed: the step cannot tell whether the page or the expected text is wrong. Compare the actual value with what you asked for before filing it.Create ticket on the run page writes a paste-ready bug report from the failed step.
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. The evidence can be an earlier step that found it, or the page having shown it earlier in the run. When one of those is missing the step names which.Fix: make sure the run sees the element before the action that removes it, for example by asserting it is visible first. To check a list became empty, count its rows before the action.When Testorim’s own plan wrote the check, a refusal like this makes the run Needs review rather than Failed: nothing showed the site doing anything wrong.
An ad sat in front of the target, or took the click. Testorim closes an ad through its own close control and clicks again; it never forces a click into one. An ad that cannot be closed, or comes back, fails the step as a test problem naming the ad network, not your site.

​
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.