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. A native Jest reporter captures results as the run happens, so steps, attachments and metadata arrive with them rather than being reconstructed from a results file.

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

Install the native reporter as a dev dependency:

npm install --save-dev @qualflare/jest

Add it to reporters alongside Jest's own, so you keep the terminal output:

// jest.config.js
module.exports = {
  reporters: ['default', ['@qualflare/jest/reporter', { environment: 'staging' }]],
};

Then run Jest as usual. It writes a report directory and makes no network calls; the CLI uploads it. Your testEnvironment is untouched:

npx jest                               # writes ./qualflare-results
qf my-project collect ./qualflare-results

Requires Jest 29 or newer and Node 18+. Sharded runs point every shard at the same output directory and collect once at the end — each process writes its own uniquely-named file, so shards never overwrite each other.

Without the reporter: the JSON results file

If you would rather not add a dependency, Jest's own --json output still works — you lose steps, attachments and metadata, but the results land:

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

Upload it with 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

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

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. Testing a mobile app too? See our Android (Espresso), iOS (XCTest), and Maestro guides. Weighing tools? See how it compares to other test management platforms, or browse all framework reporting guides. Hitting non-deterministic specs? See our guide to fixing flaky Jest tests in CI.

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