How do I produce a TestCafe HTML report?

Install a reporter — `npm i -D testcafe-reporter-html` — and run `npx testcafe chrome tests/ --reporter html:report.html`. It writes a single page you can publish as-is.

Can I keep the spec reporter for the console?

Yes. TestCafe takes multiple reporters: `--reporter spec,html:report.html` prints the usual output to the terminal and writes the HTML at the same time.

What happens to failure screenshots?

Upload the `screenshots/` folder as assets with the report. The ` ` references in the HTML are rewritten to the uploaded copies, so the screenshot loads at the URL instead of pointing at a path on a recycled build agent.

How do I get a stable link for the suite?

PATCH the same report id on every CI run. One URL per suite, one revision per run — so the link in your README or runbook never goes stale.

Can we discuss a specific failing fixture on the report?

Yes. Threads anchor to the rendered content, so the note about a flaky selector sits on that test and survives into the next run's revision.

Share a TestCafe HTML report

TestCafe's console output is good and completely ephemeral. On CI it becomes a build log; the screenshot it took of the moment the assertion failed becomes a file in a workspace that gets wiped after the job.

An HTML reporter plus a URL fixes both.

Write the report

npm i -D testcafe-reporter-html
npx testcafe chrome tests/ --reporter spec,html:report.html

spec keeps the live console output; html:report.html writes the artifact. Add screenshots on failure so there is something to look at:

npx testcafe chrome tests/ \
  --reporter spec,html:report.html \
  --screenshots path=screenshots,takeOnFails=true

Publish it

Drag report.html and the screenshots/ folder together into the app:

report.html becomes the report body.
The screenshots upload as assets and their <img src="..."> references are rewritten to the uploaded copies — which is what makes the failure evidence survive the trip.

From CI, PATCH the entry HTML and POST the screenshots as assets against the same report id:

curl -fsS -X PATCH "https://commareports.com/api/v1/reports/$REPORT_ID" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html report.html \
        --arg title "E2E — $GITHUB_REF_NAME" '{title: $title, html: $html}')"

See the API docs for the asset endpoint.

Run it with if: always() — TestCafe exits non-zero on failure, and the red run is the one worth publishing.

What review adds

Anchored threads on the failing fixture — "this selector races the animation". See commenting on HTML.
Revisions, so an intermittent failure has a visible history instead of a disputed one.
Access per report — private, team, domain-gated, or named reviewers. See the sharing model.

Limits

Entry HTML: 5 MB. Assets: 25 MB per file, 250 MB and 500 files total. Screenshots are the budget here — a full-page PNG per failing test adds up.
60 requests/minute per token.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Publish a test report →