How do I generate an xUnit HTML report?

`dotnet test --logger "html;LogFileName=xunit.html"` writes a single self-contained page, or the standalone runner does it directly: `xunit.console.exe tests.dll -html xunit.html`. Both produce one file you can publish with a single PATCH.

What about the .trx file?

A `.trx` is Visual Studio's XML result format — useful to a dashboard, unreadable to a person. Convert it (`trx2html`, ReportGenerator) or skip it and ask the runner for HTML directly.

Do I need to upload assets?

No. The HTML logger inlines its styling, so the report is a single file. Drag it in, or PATCH it — there is no asset folder to carry along.

How do I keep one URL across many runs?

PATCH the same report id every build. The URL never changes, and each run appends a revision, so you can diff this run's failures against last week's.

Can the team discuss a failure on the report itself?

Yes. Anchored threads attach to the rendered test row, so the decision about a failure lives next to the failure instead of scrolling out of a chat channel.

Share an xUnit HTML report

The .NET testing story ends the same way on most teams: a build agent runs dotnet test, a .trx lands in an artifact bucket, and the actual failure gets communicated as a screenshot of a terminal in a chat thread.

xUnit will hand you a real HTML page. The only missing step is somewhere to put it.

One command, one file

Through the SDK:

dotnet test --logger "html;LogFileName=xunit.html"
# → TestResults/xunit.html

Or the standalone console runner, which has had an HTML writer forever:

xunit.console.exe path/to/tests.dll -html xunit.html

Both write a self-contained page — styling inlined, no sibling folder. That matters: publishing is then one request with no asset step.

Publish it

Drag the file into the app, or from CI:

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 TestResults/xunit.html \
        --arg title "xUnit — $GITHUB_SHA" '{title: $title, html: $html}')"

One report id per suite. One URL that always shows the latest run, with every previous run kept as a revision behind it.

Already producing .trx?

If a pipeline stage downstream consumes the .trx, keep it and add HTML alongside — loggers compose:

dotnet test \
  --logger "trx;LogFileName=results.trx" \
  --logger "html;LogFileName=xunit.html"

The dashboard keeps its machine format; people get a link.

Publish on failure

- name: Publish xUnit report
  if: always()
  run: ./scripts/publish-report.sh

Without if: always(), dotnet test's non-zero exit skips the publish on every red build — the only builds where the report has a reader.

What review adds

Anchored threads on the failing assertion. See commenting on HTML.
Revisions, so "was this failing before my change?" is a diff.
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.
60 requests/minute per token.

Try it

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

Publish a test report →