Test in a run
One test in one run - its attempts and their evidence, the Fix panel, the runs around it, and stepping through the run's failures.
Open a test from a run’s Tests tab. The page shows that test in that run; the workflow around it is in Debugging basics.
Header
Section titled “Header”‹ Run #N goes back to the run. Next to it, Failed or flaky X of M steps through the run’s failed and flaky tests with ‹ and ›, in the order of the Tests tab. The test’s name is the title and links to its Test detail.
The line under it: the outcome, then the run’s branch, commit and author,
then the test’s file with its line (tests/checkout.spec.ts:24), browser
and shard, its time limit (for example “limit
30s”, or “Timeout · 30s” when it ran into it) and the test.fail() markers -
see Expected failures - and when the run
started. The run’s number is in ‹ Run #N; each attempt’s duration is on
its tab.
Under that, a line puts the failure in context: whether it is the same error as the test’s previous failure, and when it last passed - for example “Same error in all 3 attempts and in #63 · Last passed in #60”, or “No passing run on record”.
Open in repository beside the file opens the test’s line in your repository, at the commit this run tested - on GitHub, GitLab, Bitbucket Cloud or Azure DevOps. It needs squally-reporter 0.19.0 or newer, the run’s commit and the repository (the project’s connected GitHub repository, or the one the reporter sent). A self-hosted git server Squally cannot tell apart, or a run without a commit, shows no link. Whether a private repository opens is up to your login there - Squally fetches nothing.
History
Section titled “History”The History column on the right shows up to ten runs that contain this test, on every branch: this run, the runs before it and up to four after it. Each run shows the test’s result in that run and opens the test there. Full history opens the Test detail. On a narrow screen the history is a row of seven runs instead, oldest on the left, with up to two after this run.
Attempts
Section titled “Attempts”When the test was retried, one tab per attempt: Attempt 1, Retry 1, and so on, each with its result and duration. The page opens on the last failed attempt. On a retry that passed, a note points back to the attempt that failed, with the attempt’s annotations below it.
Each attempt shows the sections it has content for:
- Error - message and stack, an assertion split into Expected and
Received, and Playwright’s code frame. A message longer than 25 lines shows
its first 20 and Show all (N lines), which turns into Show less
once open; the copy button and the Fix prompt always take the whole
message. A diff (after
- Expected/+ Received) is coloured like Playwright’s report - lines only the expected value has in green, lines only the received one has in red - and scrolls sideways instead of wrapping, so the values stay aligned. - Annotations - the attempt’s annotations:
each one’s type with an icon, its description as written, and where it was
added (
file:line). Anissuewhose description is a singlehttps://link is that link; every other description is plain text. Descriptions are masked like error texts. Sent by squally-reporter 0.19.0 and newer, at most 20 per attempt - the section says how many more there were. - Steps - what the test did, as a tree like Playwright’s HTML report:
actions, assertions, your own
test.stepgroups, hooks and fixtures, each with its duration. Groups are folded, except the path to the failing step, which opens by itself: every group it sits in is red and expanded. The step where the test failed shows itsfile:line, and the error once, right under it - not again on the groups around it. That is the step at the error’s own location; a soft assertion that failed earlier stays red but does not take the error. Anexpect.pollis one row with its number of tries - “×3” - that opens to show each try: green when its last try passed, red only when it ended failed. Hooks are ordinary rows - Before Hooks and After Hooks. Repeated steps are one row with a count that opens to show each of them: three or more steps that differ only in numbers show the range - “Sorted by flakyRate: row 2–17 is out of order ×16”, also when a loop alternates two checks, each of which becomes its own row - and identical steps side by side show once - “The runs header did not write its sort. ×3”. Of the steps before the failing one, only the last ten show in a test withouttest.stepgroups, the last three in one with them; the rest fold into one Show N earlier steps row. Sent by squally-reporter 0.12.0 and newer, for an attempt that failed or was retried - an attempt that passed on its first try has none. Typed values never appear:Fill "•••" getByLabel('Password'). A very long list keeps 300 steps, always including the failing one, and says how many were left out. - Screenshot - click to see it full size.
- Browser console - read from the trace; without one, the section says that tracing was off.
- Test output - stdout and stderr of the test process, up to 16 KB.
- Trace - its size and how long it is kept; opens in Playwright’s Trace Viewer.
The Fix panel
Section titled “The Fix panel”On a test with a failed attempt, the Fix button at the right of the test name opens a panel on the right, “Two ways to fix this test”:
- Fix in your agent - on every plan; a prompt for your coding agent. The toggle switches between With MCP (the agent loads the failure through the MCP server) and Without MCP (the whole failure in the prompt); Copy prompt copies it. Nothing is sent. To fix all of a run’s failed and flaky tests in one go, use the run’s own Fix button.
- Fix with Squally - a suggested fix, when the plan and the project allow it; see Fix with Squally.