Karma Reporters

What the reporters Option Does

Each entry in the reporters array names a reporter plugin that receives every test event (start, individual results, completion) and formats it however it chooses — printing to the terminal, writing a file, or both. Karma ships one reporter, progress, built in; everything else requires installing a karma-*-reporter package.

Multiple reporters can run simultaneously, which is exactly how a typical CI setup shows human-readable terminal output while also writing a machine-readable JUnit XML file for the CI system to parse.

npm install --save-dev karma-junit-reporter

// karma.conf.js
config.set({
  reporters: ['progress', 'junit'],
  junitReporter: {
    outputDir: 'test-results'
  }
});

Running two reporters together is normal: one for humans reading the terminal, one for machines reading a generated file.

Common Reporter Names

reporters: ['progress']    // built-in, minimal dot/percentage output
reporters: ['dots']         // built-in, ultra-compact
reporters: ['spec']          // karma-spec-reporter, one line per spec
reporters: ['junit']          // karma-junit-reporter, XML for CI systems
reporters: ['html']            // karma-htmlfile-reporter, saved HTML report
reporters: ['coverage']          // karma-coverage, code coverage summary

• progress and dots are Karma's only truly built-in reporters, needing no extra installation.
• Every other reporter name requires installing its matching karma-*-reporter package.
• Reporter-specific settings (like junitReporter.outputDir) live in their own top-level config key, named after the reporter.
• Combining reporters is common and has no meaningful performance cost.

Reporters Cheat Sheet

The most commonly used reporters and what each is best for.

Reporter-Specific Configuration Keys

Most non-trivial reporters accept their own settings through a dedicated top-level key in karma.conf.js, conventionally named after the reporter itself (junitReporter, htmlReporter, coverageReporter).

config.set({
  reporters: ['progress', 'junit', 'html'],
  junitReporter: { outputDir: 'reports/junit' },
  htmlReporter: { outputFile: 'reports/tests.html' }
});

File-Writing vs. Terminal-Printing Reporters

It helps to mentally separate reporters into two categories: those that print to the terminal for a human watching the run live (progress, dots, spec), and those that write structured output to disk for later consumption by other tools (junit, html, coverage).

• Terminal reporters: fast feedback while actively developing or debugging.
• File-writing reporters: consumed later by CI dashboards, coverage tools, or archived for audits.
• A typical CI setup uses at least one of each simultaneously.
• File-writing reporters usually need an explicit output directory/file configured, or they default somewhere unexpected.

Common Mistakes

• Listing a reporter name without installing its matching karma-*-reporter package first.
• Not configuring an output directory for file-writing reporters and later hunting for where files landed.
• Running only a terminal reporter in CI, leaving no machine-readable artifact for dashboards or history.
• Assuming all reporters share one config namespace instead of each using its own dedicated top-level key.

Key Takeaways

• reporters names one or more plugins responsible for formatting test output.
• progress and dots are the only reporters truly built into Karma itself.
• Reporter-specific settings live under their own top-level config key, named after the reporter.
• Combining a terminal reporter with a file-writing reporter is the standard, recommended CI pattern.