Screenshots and video
Stored screenshots and recordings carry a small Testorim mark in the corner.
A recording is left unmarked when the service is at capacity. Step
screenshots used for visual comparison never carry it, because their pixels
are compared.
A fuzz variant keeps no recording; the batch’s control run does. A stopped
run keeps no recording, trace or final screenshot.
Evidence finishes after the run
The report and the verdict come first, and the run is complete from that moment. The final screenshot, the accessibility scan, the recording and the trace are saved in the background afterwards. While they are, the run page says so and refreshes itself. If one could not be saved, the run page says which and why, for example that the recording timed out, instead of leaving a gap.Per-step snapshots
Each step records the page before and after it acted: the URL, the page title, and the visible text, with advertisements left out. These snapshots let the report say that the address moved between resolving a target and acting on it. They are also what the silent-click check compares: a click that changes neither the address nor anything on the page passes with a warning saying so.Assertion evidence
Every assertion stores three things: the matcher that decided it, the condition that was expected, and the actual state read back off the element:enabled, the text it held, the value in the input, or not present.
The report is required to quote the actual value and forbidden from inferring
an attribute nobody observed. A run that checked visibility cannot report that
something was disabled.
Console and network
Console messages and network requests are captured per step, in the window around the action. They appear on the run page and feed API assertions. A redirect is not counted as a failed request; only a status of 400 and up, or no response at all, is. A step with an API assertion also stores the matched request: its URL, method and status, or the reason nothing matched. Cookie values and credential headers in stored responses are dropped.Accessibility
The finished page is scanned and its violations stored with the run.Performance
Metrics are collected per page that loads: LCP, FCP, TTFB. If the procedure has a performance budget, a breach marks the run’s performance statusdegraded.
Timings taken while other runs shared the test machine are marked as such and
shown without a grade, because they measure our load rather than your site.
They are never judged against a budget. A page reached without a new page
load (a client-side route change) is shown as reached in place, with no load
timings.
Visual diffs
For a step with a saved baseline for that(procedure, step, viewport)
combination, a pixel comparison runs and the run page shows baseline, actual
and difference side by side.
Downloads
A file a step downloads is captured and retained whether or not the step asserted anything about it.Where to find it all
- The run page at
/runs/<run-id>, holding everything above: every step with its value or condition, the value read back, expected and actual, the verdict and the time, plus one Artifacts section. - A share link, a sanitised public copy: no cookies, no environment headers, no browser storage state, no console or network detail. Revocable, optionally expiring.
- The API:
GET /api/runs/{id}returns the run with artifact URLs. Those URLs are signed and expire after an hour; fetch the run again for fresh ones.