Skip to content

Karma Coverage Reporter Formats

karma-coverage can generate coverage data in several different formats simultaneously, each suited to a different audience: humans browsing a report, CI dashboards, or other tooling. This lesson covers the most common formats.

Generating Multiple Formats at Once

coverageReporter.reporters accepts an array, so you can generate several output formats from a single instrumented run — no need to run your suite multiple times to get both a browsable HTML report and a CI-friendly format.

coverageReporter: {
  dir: 'coverage/',
  reporters: [
    { type: 'html', subdir: 'html' },
    { type: 'text-summary' },
    { type: 'lcovonly', subdir: '.', file: 'lcov.info' },
    { type: 'cobertura', subdir: '.', file: 'cobertura.xml' }
  ]
}

Each entry writes its own output under coverageReporter.dir, organized by the optional subdir key.

Common Format Types

html          // browsable, clickable coverage report
text          // full text table printed to the terminal
text-summary  // one-line summary printed to the terminal
lcov          // lcov.info format, widely supported by tools/IDEs
lcovonly      // lcov.info only, without the accompanying HTML
cobertura     // Cobertura XML, common in Jenkins pipelines
json-summary  // machine-readable JSON summary, useful for custom scripts
  • html is best for local, human-driven exploration of exactly what's covered.
  • text-summary is a good lightweight addition for quick terminal visibility without extra files.
  • lcov/lcovonly integrates with many editor extensions that show inline coverage gutters.
  • cobertura specifically targets Jenkins' built-in Cobertura coverage plugin.

Coverage Format Cheat Sheet

Choosing the right format for the right consumer.

Format Best For
html Humans browsing coverage in a web browser
text-summary Quick terminal glance without generating files
lcov / lcovonly Editor extensions and many generic coverage tools
cobertura Jenkins pipelines with the Cobertura plugin
json-summary Custom scripts parsing coverage programmatically

Using lcov.info for Editor Coverage Gutters

Many editor extensions (including popular VS Code coverage-gutter plugins) read a project's lcov.info file to show inline covered/uncovered line markers directly in the editor, right next to the code — a fast feedback loop while writing new tests.

coverageReporter: {
  reporters: [
    { type: 'lcovonly', subdir: '.', file: 'lcov.info' }
  ]
}

Feeding CI Coverage Dashboards

Many hosted coverage dashboards (like Codecov or Coveralls) accept lcov.info directly as an upload, making it a practical universal format even outside of editor tooling.

# Example CI step
npx karma start --single-run
npx codecov -f coverage/lcov.info

Common Mistakes

  • Generating only html and then struggling to feed coverage data into a CI dashboard that expects lcov or cobertura.
  • Forgetting subdir when generating multiple formats, causing them to overwrite each other's default output location.
  • Not realizing lcovonly and lcov differ slightly in what additional files they generate.
  • Choosing cobertura for a non-Jenkins pipeline when lcov would integrate more broadly.

Key Takeaways

  • coverageReporter.reporters accepts multiple format entries, generated from a single test run.
  • html is best for humans; lcov/cobertura/json-summary serve tooling and CI dashboards.
  • lcov.info is widely supported by editor extensions and hosted coverage services alike.
  • Choosing formats deliberately, based on actual consumers, avoids generating unused report files.

Pro Tip

Generate lcov.info even if your team doesn't currently use a hosted coverage dashboard. It costs nothing extra to produce and instantly unlocks editor-integrated coverage gutters for anyone on the team who installs the relevant extension.