Testland
Browse all skills & agents

jest-coverage-analysis

Configures Jest's built-in coverage (Istanbul-instrumented `babel` provider or V8-native `v8` provider), wires the right `coverageReporters` for downstream consumption (`lcov` for SaaS / cross-tool, `cobertura` for Jenkins, `text-summary` for terminal, `html` for human review), authors per-file `coverageThreshold` rules that focus the gate on critical paths (vs the global-only foot-gun), and parses the per-file JSON output for PR-time deltas. Use when the project tests with Jest (or Vitest, which uses the same Istanbul/V8 provider) and the team needs PR-time coverage signal that's both local-runnable and CI-gateable.

Install with skills.sh (any agent)

npx skills add testland/qa --skill jest-coverage-analysis
View source

jest-coverage-analysis

Overview

Jest ships with built-in coverage. Per jest-config (opens in new window), on coverageProvider:

"Indicates which provider should be used to instrument code for coverage. Allowed values are babel (default) or v8."

The babel provider runs the project through Istanbul-style instrumentation; v8 uses the Node V8 engine's native coverage hooks (faster, but with subtler edge cases around source maps).

Coverage output goes to coverageDirectory (default coverage/) in the formats listed in coverageReporters. The defaults are ["clover", "json", "lcov", "text"] (jest-config (opens in new window)) - lcov is the most useful for cross-tool consumption (see lcov-analysis).

When to use

  • The project tests with Jest or Vitest (Vitest uses the same Istanbul / V8 coverage stack and the same config keys).
  • A PR coverage gate needs per-file thresholds, not just a global number.
  • A SaaS coverage dashboard (Codecov, Coveralls) consumes LCOV; the default coverageReporters already produces it.
  • A Jenkins pipeline expects Cobertura XML.

If the project is multi-language (Jest + Java + Python), see coverage-diff-reporter for the cross-tool aggregation pattern; this skill is the Jest-specific piece.

Step 1 - Pick the provider

Per jest-config (opens in new window):

ProviderProsCons
babelMature; Istanbul ecosystem; rich ignore comments.Slower (instruments via Babel transform); may differ from production semantics.
v8Faster (uses V8's native coverage); closer to runtime truth.Source-map edge cases; some files may show partial coverage where Babel is clean.
/** @type {import('jest').Config} */
module.exports = {
  coverageProvider: 'v8',   // or 'babel'
};

Each provider has a different ignore-comment syntax (jest-config (opens in new window)):

  • babel: /* istanbul ignore next */
  • v8: /* c8 ignore next */

Don't mix; switching providers requires updating ignore comments across the codebase.

Step 2 - Choose coverageReporters

Per jest-config (opens in new window), "Any istanbul reporter (opens in new window) can be used." The useful ones:

ReporterOutputUse for
lcovcoverage/lcov.info + HTML in coverage/lcov-report/SaaS upload, cross-tool diffing.
coberturacoverage/cobertura-coverage.xmlJenkins, Azure DevOps, GitLab pipelines.
clovercoverage/clover.xmlAtlassian Bamboo (legacy).
jsoncoverage/coverage-final.jsonProgrammatic post-processing (Step 5).
json-summarycoverage/coverage-summary.jsonQuick whole-repo number for dashboards.
text-summaryTerminal output (compact)CI log readability.
textTerminal output (per-file)Local dev.
htmlcoverage/lcov-report/index.htmlHuman review (drill-down per file).

Pragmatic default for a CI + SaaS + local-dev setup:

coverageReporters: ['lcov', 'json', 'text-summary', 'html']

lcov for the dashboard, json for programmatic post-processing, text-summary for the CI log, html for the human.

Step 3 - Per-file thresholds (the gate-correctness pattern)

Per jest-config (opens in new window), coverageThreshold accepts global, glob, or path-specific rules:

coverageThreshold: {
  global: {
    branches: 50,
    functions: 50,
    lines: 50,
    statements: 50,
  },
  './src/components/': {
    branches: 40,
    statements: 40,
  },
  './src/reducers/**/*.js': {
    statements: 90,
  },
  './src/api/very-important-module.js': {
    branches: 100,
    functions: 100,
    lines: 100,
    statements: 100,
  },
},

The pattern is lower the global, raise the critical paths. A 50% global keeps refactors flowing; a 100% per-file rule on a payment-processing module ensures any drop is caught immediately.

"Jest will fail if thresholds aren't met." (jest-config (opens in new window))

"Negative numbers = maximum uncovered entities allowed."

The negative-number form is useful for legacy modules: statements: -10 allows up to 10 uncovered statements before failing. Lets the team ratchet down over time without setting an aspirational percentage.

Verify the gate fires: run npx jest --coverage with a critical-path file left below its coverageThreshold and confirm Jest exits non-zero with a coverage-threshold-not-met error. If it exits 0, check that collectCoverageFrom (Step 4) includes the file and that the coverageThreshold path key matches the file's path, then re-run.

Step 4 - Scope collectCoverageFrom

Per jest-config (opens in new window):

"An array of glob patterns indicating which files should have coverage collected, even if they have no tests."

collectCoverageFrom: [
  'src/**/*.{js,jsx,ts,tsx}',
  '!src/**/*.d.ts',
  '!src/**/*.stories.{js,ts,tsx}',
  '!src/index.js',
],

Without this, coverage only counts files that a test imported. Files with no test at all disappear from the report - coverage looks artificially high. Always set collectCoverageFrom for an honest denominator.

Step 5 - Parse the JSON output

The json reporter writes coverage/coverage-final.json, keyed by absolute path, where s = per-statement hit counts, f = per-function, and b = per-branch arm. Count the non-zero entries for a per-file percentage:

import { readFileSync } from 'node:fs';

const data = JSON.parse(readFileSync('coverage/coverage-final.json', 'utf8'));
const pct = obj => { const v = Object.values(obj); return (v.filter(c => c > 0).length / v.length) * 100; };

for (const [path, file] of Object.entries(data)) {
  console.log({ path, stmt: pct(file.s), fn: pct(file.f) });
}

The full parser (branch-arm handling plus the coverage-summary.json shortcut for whole-repo numbers) is in references/parsing-and-anti-patterns.md.

Step 6 - Vitest equivalent

Vitest uses the same Istanbul / V8 stack with vitest --coverage:

// vitest.config.ts
import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    coverage: {
      provider: 'v8',
      reporter: ['text-summary', 'lcov', 'json', 'html'],
      include: ['src/**/*.{ts,tsx}'],
      thresholds: {
        global: { branches: 50, functions: 50, lines: 50, statements: 50 },
        'src/api/**/*.ts': { branches: 100, functions: 100, lines: 100, statements: 100 },
      },
    },
  },
});

Key naming differences vs Jest:

  • collectCoverageFromcoverage.include
  • coverageReporterscoverage.reporter
  • coverageThresholdcoverage.thresholds

The output formats and PR-gating logic are identical - the downstream parser works against either.

Step 7 - CI shape

- name: Run tests with coverage
  run: npx jest --coverage --coverageReporters=lcov,json,text-summary

- name: Show summary in CI log
  run: cat coverage/coverage-summary.json

- name: Upload to dashboard
  if: always()
  uses: codecov/codecov-action@v4
  with:
    files: coverage/lcov.info
    token: ${{ secrets.CODECOV_TOKEN }}

- name: Per-file delta vs main
  if: github.event_name == 'pull_request'
  run: node scripts/jest-pr-comment.mjs

--coverage activates collectCoverage: true, --coverageReporters overrides config-side reporter selection.

Anti-patterns

The recurring coverage-gate foot-guns - collectCoverage: false in CI, skipping collectCoverageFrom (inflated denominator), global-only thresholds, mixing babel / v8 ignore comments, and a 100% global rule that gets coverage disabled after the first refactor - with the fix for each are catalogued in references/parsing-and-anti-patterns.md.

Limitations

  • Source-map fidelity affects V8 provider. Files that go through multiple transforms (Babel + TS + bundler) may show wrong file paths or partial coverage under the V8 provider; switch to babel if so.
  • Coverage doesn't equal correctness. A 100%-covered function with if (x) {} (empty body) measures as covered but tests nothing.
  • Async branches are tricky. A function that resolves a Promise may show the resolved path as covered but miss the rejection arm unless tests explicitly throw.
  • Multi-project (projects: [...]) coverage is per-project. Aggregate via the --coverageDirectory of each project + a combiner script if a single repo number is needed.

References

  • jest-config (opens in new window) - collectCoverage, coverageProvider (babel vs v8), coverageReporters (defaults ["clover","json","lcov","text"]), coverageThreshold (global + glob + path), collectCoverageFrom, coveragePathIgnorePatterns.
  • lcov-analysis - the LCOV file Jest emits feeds this parser for cross-tool diffing.
  • cobertura-analysis - Jest also emits Cobertura XML when configured; this parser consumes it.
  • coverage-diff-reporter - PR-comment formatter built on top of the parsed Jest output.
  • test-coverage-targeter - picks which uncovered branches to target, given the Jest output.

Parsing coverage-final.json and coverage-gate anti-patterns

View source (opens in new window)

Parsing coverage-final.json and coverage-gate anti-patterns

Companion detail for jest-coverage-analysis. The Jest / Vitest config in SKILL.md is the runnable core; this file holds the full JSON parser and the anti-pattern catalog.

The coverage-final.json shape

The json reporter writes coverage/coverage-final.json with a per-file structure keyed by absolute path:

{
  "/abs/path/src/checkout/cart.ts": {
    "path": "/abs/path/src/checkout/cart.ts",
    "statementMap": { "0": { "start": {}, "end": {} } },
    "fnMap": { },
    "branchMap": { },
    "s": { "0": 42, "1": 42, "2": 0 },
    "f": { "0": 42, "1": 0 },
    "b": { "0": [42, 0] }
  }
}

s = per-statement hit counts; f = per-function; b = per-branch arm.

Full per-file parser

// scripts/parse_jest_coverage.js
import { readFileSync } from 'node:fs';

const data = JSON.parse(readFileSync('coverage/coverage-final.json', 'utf8'));

for (const [absPath, file] of Object.entries(data)) {
  const stmts = Object.values(file.s);
  const stmtPct = (stmts.filter(c => c > 0).length / stmts.length) * 100;

  const fns = Object.values(file.f);
  const fnPct = (fns.filter(c => c > 0).length / fns.length) * 100;

  // Branch coverage: each entry is an array of arm hit counts.
  const branchEntries = Object.values(file.b);
  const branchTotal = branchEntries.flat().length;
  const branchHit = branchEntries.flat().filter(c => c > 0).length;
  const brPct = branchTotal === 0 ? 100 : (branchHit / branchTotal) * 100;

  console.log({ path: absPath, stmtPct, fnPct, brPct });
}

The coverage-summary.json file (from the json-summary reporter) is the pre-aggregated version when per-statement detail isn't needed.

Anti-patterns

Anti-patternWhy it failsFix
collectCoverage: false in CINo coverage data emitted; downstream gate is empty.--coverage flag in the test command (Step 7).
Skipping collectCoverageFromFiles with no test silently absent from denominator; coverage inflated.Always set explicitly (Step 4).
coverageThreshold.global only, no per-path rulesA new module under src/api/ joins at 0% coverage; global drops by 0.3pp; gate passes.Per-path rules for critical modules (Step 3).
Mixing babel and v8 ignore commentsOne provider misses the ignore; coverage drops mysteriously.Pick one; grep-replace if switching.
Using coverage-final.json as the gate inputPer-statement detail is huge; gate scripts slow.coverage-summary.json for whole-repo + lcov.info for per-line drilldown.
coverageDirectory: '/tmp/...' outside the repoCI artifact upload step misses it.Keep in coverage/ (default).
Threshold set at 100% on a global ruleFirst refactor fails the build; team disables coverage entirely.Set globals at the maintainable floor, not aspirational ceiling.

Related skills

allure-reports

Configures Allure Report (test-runner adapter install, `allure-results` directory wiring, `categories.json` for failure classification, `history-trend.json` retention via the copy-history-between-runs pattern), runs the Allure CLI to convert `allure-results` to a static HTML site, and uploads the report as a CI artifact. Use when the team needs richer test reporting than JUnit XML - step-level attachments, per-test history, retry tracking, and severity / epic / feature labeling across framework-agnostic adapters (pytest, Jest, JUnit, TestNG, NUnit, Mocha). As a rich static HTML report generator, it is the open-source alternative to extentreports (JVM/.NET per-test HTML narrative); for hosted cross-run flakiness analytics rather than a static per-run report use currents-integration.

cobertura-analysis

Parses Cobertura XML coverage reports (the JVM-canonical format originally from the cobertura-cobertura tool, also emitted by JaCoCo `--coverage-xml`, coverage.py `--xml`, Istanbul / Jest `cobertura` reporter, gocover-cobertura, and dotnet's `coverlet`). Walks the coverage-04 DTD structure (coverage → packages → classes → methods → lines + conditions), computes per-file deltas, and emits PR-time gating verdicts. Use when the existing CI emits Cobertura XML - typical for JVM-heavy stacks and tools that ship Cobertura as a default reporter.

coverage-diff-reporter

Builds a per-PR coverage delta report from any pair of LCOV / Cobertura / JSON coverage outputs (current run + baseline from the merge target) - emits a per-file table with line% / branch% deltas, called-out new files, hidden drops (overall +0.1pp but one file -8pp), and a single-line PR-comment summary. Use when the team has coverage in CI but needs human-readable PR feedback that points at the specific file the reviewer should focus on, not just an aggregate number.

coverage-py-analysis

Configures coverage.py for Python projects - wires `coverage run` (replacing `python` for instrumentation), enables branch coverage via the `--branch` flag or `branch = True` config, manages the `.coverage` data file (single-process and `combine` for parallel pytest-xdist runs), authors `.coveragerc` with `source` / `omit` / `fail_under`, and emits the format the downstream tool needs (`coverage report` for terminal, `coverage xml` for Cobertura, `coverage html` for human review, `coverage lcov` for SaaS, `coverage json` for programmatic post-processing). Use for any Python test stack (pytest, unittest, nose) that needs PR-time coverage signal.

currents-integration

Wires Currents.dev cross-run test analytics into a Playwright suite: installs `@currents/playwright`, authors `currents.config.ts` (env-sourced `recordKey` + `projectId`), registers `currentsReporter()`, enables trace/video/screenshot artifacts, and runs via `npx pwc` so per-test traces stream to the Currents dashboard with over-time flakiness, slowest-test, and pass-rate trends. Use when a Playwright suite needs hosted cross-run suite-health analytics; for a static per-run report use extentreports or allure-reports, and to sync results into Jira test management use zephyr-integration or xray-integration.

extentreports

Configures ExtentReports v5 for a JVM (or .NET via `extentreports-dotnet`) test run: wires `ExtentSparkReporter`, `attachReporter`, `createTest`, the `info`/`pass`/`warning`/`skip`/`fail` log chain, screenshots via `MediaEntityBuilder`, hierarchical `createNode` parent/child tests, and category/author/device labels, emitting a static HTML report alongside JUnit XML for CI artifact upload. Use when a suite on the Aventstack ExtentReports stack wants a richer per-test HTML narrative than JUnit XML gives; for code-coverage reporting use jacoco-analysis, and for hosted cross-run flakiness analytics use currents-integration.

jacoco-analysis

Configures JaCoCo for JVM projects (Java / Kotlin / Scala / Groovy) - wires the runtime agent via `jacoco-maven-plugin` `prepare-agent`, generates per-build reports (HTML / XML / CSV) via the `report` goal, gates the build via the `check` goal with element / limit / minimum rules, parses the six native counters (instructions, branches, lines, methods, classes, cyclomatic complexity), and converts JaCoCo XML to LCOV / Cobertura when downstream tools need a different format. Use when the JVM build is Maven / Gradle and the team wants the canonical JVM coverage tool - or to convert JaCoCo output for cross-language coverage aggregation.

junit-xml-analysis

Parses JUnit-format XML reports (the de-facto interchange format every CI ingests - Jenkins, GitHub Actions, GitLab, Buildkite, CircleCI) into structured, machine-readable per-suite and per-case metrics tables (passed / failed / errored / skipped, time, classname, message, stack), groups failures by classname for trend analysis, and distinguishes "new failures vs flakes" by cross-referencing the `flakyFailure` and `rerunFailure` rerun elements. Use when the downstream consumer is a dashboard, script, or aggregator - not when the goal is a human-readable prose summary (use test-run-summary-author for that). Single-run, in-XML aggregation only; for cross-run cross-environment roll-ups, use a cross-run test-suite aggregator.

lcov-analysis

Parses LCOV `.info` text files (the de-facto coverage interchange format produced by gcov, llvm-cov, Coverage.py via `py2lcov`, JaCoCo via `xml2lcov`, Devel::Cover, Jest via `lcov` reporter, NYC, and most others). Extracts per-file line / function / branch metrics from the canonical record keywords (TN/SF/FN/FNDA/FNF/FNH/BRDA/BRF/BRH/DA/LH/LF), computes the diff vs a baseline, and emits per-file gating verdicts. Use for PR coverage gates that don't depend on a specific language runtime.

test-coverage-targeter

Builds a "what to test next" recommendation by combining a coverage report (LCOV / Cobertura / coverage.py JSON / Jest JSON / JaCoCo XML) with the PR's `git diff`, ranking uncovered branches by risk × cost - risk weighted by McCabe cyclomatic complexity and code-churn frequency, cost weighted by the unit-test pyramid layer (unit tests cheaper than integration than E2E). Emits a prioritized list with concrete file:line targets and the test layer recommended for each. Use when a team has the budget to write 5 - 10 new tests and needs help picking which uncovered code to target first instead of blindly chasing 100% coverage.

test-run-summary-author

Build-an-X workflow that turns a structured test-run artifact (JUnit XML, Allure JSON, TestRail / Xray / Zephyr export) plus optional release context (version, build URL, deploy target) into a narrative markdown summary for release notes, an exec status update, or a stand-up Slack post. Distinct from the per-framework parsers junit-xml-analysis / allure-reports / coverage-diff-reporter, which emit structured tabular reports: this skill takes the same data and writes the human-readable narrative. Use when a manager needs a draft release note or stand-up summary from a single run; for cross-run trend analytics use currents-integration.

testrail-integration

Syncs test runs / results / cases between an automated test suite and TestRail (Gurock / Idera) - opens a Test Run for the build (`add_run`), batches per-case results back via `add_results_for_cases` (preferred over per-test `add_result_for_case` - N+1 API calls vs 1), maps the test framework's pass/fail/skip to TestRail status IDs, and attaches build URL + version + elapsed time. Use when the team's test management is standalone TestRail (not a Jira app) and automated suites must update it without a human copy-paste step; when the TCM is instead a Jira app use xray-integration (Xray) or zephyr-integration (Zephyr Scale), and for hosted cross-run flakiness analytics rather than TCM sync use currents-integration.

xray-integration

Imports CI test results into Xray for Jira - authenticates via the `client_id` + `client_secret` → JWT exchange (Cloud) or PAT / Basic (Server), posts to the format-specific `/api/v2/import/execution/*` endpoint (`/junit` for JUnit XML, `/cucumber` for Cucumber JSON, `/nunit` / `/testng` / `/robot` for the others), and maps automated results to existing Xray Test issues via the `xray-junit-extensions` `@XrayTest(key="...")` annotation. Use when the team uses the Xray Jira app to manage Test, Test Set, and Test Execution issue types and CI must keep those execution issues in sync; for the other Jira TCM app use zephyr-integration (Zephyr Scale), for standalone non-Jira TestRail use testrail-integration, and for hosted cross-run flakiness analytics rather than TCM sync use currents-integration.

zephyr-integration

Syncs automated test results to Zephyr Scale for Jira (formerly TM4J / SmartBear / Adaptavist): picks the product variant (Scale Cloud / Squad / Enterprise), authenticates with a long-lived API token as a Bearer header, opens a Test Cycle per build, posts executions via `POST /testexecutions` (or bulk JUnit via `/automations/executions/junit`), and maps test methods to Zephyr Test Cases via `@TestCaseKey`-style annotations. Use when the team's Jira test management is Zephyr Scale; for the Xray Jira app use xray-integration, for standalone TestRail use testrail-integration, and for over-time flakiness analytics rather than TCM sync use currents-integration.