Jest test reporting

Jest gives you a terminal summary and a --json results file — but that’s a file, not a dashboard, and it’s gone next run. Qualflare ingests your Jest results and turns them into hosted, historical reporting: AI clusters failures by root cause, scores flaky tests from run history, and rates each launch’s risk — across every CI run and every package in your monorepo.

Why Jest’s built-in output isn’t enough

Jest’s reporting is intentionally local: rich terminal output, a machine-readable --json file, and — if you add a package like jest-html-reporters — a local HTML report. All of it is per-run and lives on the machine that ran it. Nothing collects results across CI runs, aggregates the packages in a monorepo, or tells you whether a test has been getting flakier over the last two weeks. For that you need something that stores results over time and analyzes them.

Send Jest results to Qualflare

Two steps. First, have Jest write a JSON results file — this is built into Jest, no extra reporter required:

# Jest writes a JSON results file natively — no extra reporter needed
npx jest --json --outputFile=jest-results.json

Then upload that file with the Qualflare CLI. The --format jest flag uses the Jest-aware parser; the CLI attaches your Git branch and commit automatically:

# Upload to Qualflare with the Jest-aware parser
qf my-project collect jest-results.json --format jest

In CI, that’s one extra step after your test run (GitHub Actions shown — GitLab CI, CircleCI, and Jenkins work the same way). Authenticate the CLI once with your Qualflare access token, stored as a CI secret — see the CLI docs.

# .github/workflows/tests.yml
- name: Run Jest
  run: npx jest --json --outputFile=jest-results.json

- name: Upload results to Qualflare
  if: always() # upload even when tests fail — that's the point
  run: qf my-project collect jest-results.json --format jest

What you get on top of Jest

• AI failure clustering. When a single broken mock or import takes down 40 tests, Qualflare groups them by root cause — so you fix one thing instead of scrolling 40 stack traces.
• Flaky detection from history. Qualflare scores each test’s flakiness from its pass/fail record across runs — the accurate, retry-free method. (Jest doesn’t retry by default; if you emit JUnit XML via jest-junit, any in-run retries are read too.)
• Monorepo aggregation. Upload each package’s JSON and Qualflare merges them into one launch — a single picture across every project in the repo.
• Per-launch risk. Each CI run becomes a launch with a risk rating, the failing areas, and recommended next steps — a ship / don’t-ship signal that arrives with the results.
• History, trends & defects. Pass rate, slowest tests, and flakiness over time across branches — plus a defect you can open straight from a failing run.

Raw Jest output vs Qualflare

Complementary: keep --json / jest-html-reporters for local runs, add Qualflare for hosted, historical CI observability.

Qualflare works the same with Playwright, pytest, Cypress, JUnit and 20+ more frameworks. Weighing tools? See how it compares to other test management platforms, or browse all framework reporting guides.

Monorepos, projects, and Jest sharding

Jest is the framework most likely to be running inside a monorepo, and its projects feature runs every package’s suite in one invocation — which means one results file already covering the whole repo, with each test tagged by its project:

// jest.config.js — multi-project monorepo: one run, every package reported
module.exports = {
  projects: ['<rootDir>/packages/*'],
};

For big suites, Jest 28+ added native sharding. Unlike Playwright there’s no blob-merge step — each shard writes its own JSON, and you pass all of them to a single qf collect (it takes multiple files and globs) so the whole sharded run lands as one launch:

# Jest 28+ shards natively — one JSON per shard
npx jest --shard=1/3 --json --outputFile=jest-results-1.json

# Collect every shard's file in ONE command so the run stays one launch
qf my-project collect jest-results-*.json

One thing Jest deliberately lacks is built-in retries at the runner level — jest.retryTimes() exists per test file but most teams run without retries, so flakiness shows up as raw intermittent failures rather than recorded retry attempts. That makes cross-run history the only reliable way to separate a flaky Jest test from a real regression — exactly what hosted reporting adds.

Frequently asked questions