Open-Source DevOps · dorny

test-reporter

Test Reporter is a GitHub Action that automatically parses test results from popular frameworks (Jest, JUnit, pytest, etc.) and displays them as GitHub Check Runs and job summaries with code annotations. It supports 10+ languages and frameworks, providing pass/fail counts and linking failures directly to source code.

Talk to DEV.co Discuss Implementation

Source: GitHub — github.com/dorny/test-reporter

1.2k

GitHub stars

294

Forks

TypeScript

Primary language

MIT

License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

Field	Value
Repository	dorny/test-reporter
Owner	dorny
Primary language	TypeScript
License	MIT — OSI-approved
Stars	1.2k
Forks	294
Open issues	119
Latest release	v3.0.0 (2026-03-21)
Last updated	2026-06-30
Source	https://github.com/dorny/test-reporter

What test-reporter is

A TypeScript-based GitHub Action that consumes XML or JSON test result files, parses them via framework-specific parsers, and publishes results via GitHub's Check Runs API with inline code annotations. It handles both simple single-workflow and complex forked-repository scenarios via artifact-based workflows, outputting conclusion and test metrics as action outputs.

Quickstart

Get the test-reporter source

Clone the repository and explore it locally.

terminalbash

1git clone https://github.com/dorny/test-reporter.git2cd test-reporter3# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Multi-language CI/CD pipelines

Standardize test reporting across projects using different frameworks (Java+JUnit, JavaScript+Jest, Python+pytest, etc.) in a single unified GitHub interface without maintaining multiple reporting tools.

Pull request quality gates in public repositories

Enable forked-repository contributions by using two-workflow pattern (artifact upload in fork context, report generation in main repo context) to securely report test failures without exposing write tokens.

Developer feedback at point of failure

Annotate failing tests directly in GitHub diffs and PR reviews, reducing time to identify which test failed and where in the code the failure occurred.

Implementation considerations

Test result files must be in supported XML or JSON format; if using an uncommon test runner, verify it can export to one of the supported formats or generate a compatible output.
For forked PRs, follow the two-workflow pattern (CI + Test Report) to avoid token permission issues; single-workflow mode works only for non-forked branches.
Set `if: ${{ !cancelled() }}` to ensure test results are reported even if test execution fails, preventing silent misses of critical failures.
Use `max-annotations` (default 10, max 50) judiciously; GitHub has hard limits on inline annotations, so large test suites may need summary-only mode.
Verify working-directory and path glob patterns match your artifact/output structure; mismatched paths result in 'no test results found' and potential fail-on-empty errors.

When to avoid it — and what to weigh

Proprietary or uncommon test frameworks — If your project uses a test framework not in the supported list (Dart, Flutter, Go, Java, JavaScript, Python, PHP, Ruby, Swift, .NET), you will need to contribute a parser or generate compatible output format.
Real-time streaming or live test monitoring — This action processes completed test result files post-execution. It does not support real-time test streaming or continuous monitoring during test execution.
Offline or airgapped CI environments — The action requires GitHub API access to post Check Runs and job summaries; environments without outbound HTTPS connectivity to api.github.com will not work.
Complex cross-repository test aggregation — While it can process multiple result files in a single workflow, orchestrating test results across many dependent repositories requires external tooling beyond the action's scope.

License & commercial use

Licensed under MIT (MIT License), which is a permissive OSI-approved open-source license permitting free use, modification, and distribution with no restrictions on commercial use. License is unambiguous and widely compatible.

MIT license explicitly permits commercial use without restriction. No licensing fees, proprietary dependencies, or commercial restrictions identified in provided data. Organizations may use this action in production without legal concerns related to the license itself.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

Signal	Assessment
Maintenance	Active
Documentation	Strong
License clarity	Clear
Deployment complexity	Low
DEV.co fit	Strong
Assessment confidence	High

Security considerations

Action operates within GitHub Actions runtime with token-based API access. Fork-triggered workflows execute with read-only tokens by design, mitigated by the recommended two-workflow pattern. No findings regarding code injection, secrets leakage, or supply-chain risks disclosed in provided data. Review IAM permissions for custom token usage.

Alternatives to consider

Codecov / Coveralls

Focus on code coverage metrics and trends over time rather than test result parsing; different use case if coverage tracking is the primary goal.

GitHub's native test result reporting (via workflow commands)

GitHub Actions supports native `::error::` and `::notice::` commands for annotations; dorny/test-reporter abstracts framework-specific parsing and provides richer UI (Check Runs, summaries, metrics) with less YAML boilerplate.

JUnit report plugins (Jenkins, GitLab CI, etc.)

Platform-specific solutions; if migrating away from GitHub Actions or using multi-platform CI, evaluate platform-native test reporting.

Software development agency

Build on test-reporter with DEV.co software developers

Evaluate Test Reporter for your GitHub Actions workflows. Review the supported frameworks, test the simple workflow example in a non-critical repo, and assess token/permission requirements for your CI environment.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

jest ts-jest vscode

Related on DEV.co

Explore the category and the services that help you build with it.

Open-Source DevOps DevOps & CI/CD Application Development Talk to DEV.co

test-reporter FAQ

Does this action work with pull requests from forked repositories?

Not with a single workflow due to fork-triggered workflows receiving read-only tokens. Use the recommended two-workflow pattern: run tests in fork (CI workflow), upload artifact, then create report on main branch (Test Report workflow triggered via workflow_run).

Which test frameworks are supported?

Supports 10+ frameworks across 9 languages: dotnet test (xUnit/NUnit/MSTest), Dart/Flutter test, Go test, JUnit (Java), Jest/Mocha (JavaScript), pytest/unittest (Python), PHPUnit/Nette Tester (PHP), RSpec (Ruby), and Swift xUnit. Requires test results in XML or JSON format.

What permissions does the action require?

Requires `permissions: { checks: write }` at minimum to create Check Runs. Also typically needs `actions: read` (to download artifacts in workflow_run scenarios) and `contents: read`. Default GitHub token usually has these; verify if using custom PAT.

Can I fail the workflow if tests fail?

Yes, set `fail-on-error: 'true'` (default) to fail the step if test report contains any failed tests. Also set `fail-on-empty: 'true'` (default) to fail if no test results are found.

Software development & web development with DEV.co

Adopting test-reporter is usually one piece of a larger software development effort. As a software development agency, DEV.co provides software development services and web development expertise — pairing senior software developers and web developers with your team to design, build, and operate open-source devops software in production.

Ready to unify your test reporting across frameworks?

Talk to DEV.co Schedule a Consultation