Karma Do's and Don'ts

This lesson presents recommended practices directly alongside their discouraged counterparts, for a faster scan than a plain best-practices list — useful as a quick pre-review checklist for a karma.conf.js change.

Configuration Do's and Don'ts

Configuration is where small, easy-to-miss mistakes compound into confusing, hard-to-debug issues later. The comparisons below focus on the differences that matter most in practice.

// DO: branch on environment inside one shared config
browsers: [process.env.CI ? 'ChromeHeadlessCI' : 'ChromeHeadless']

// DON'T: maintain two nearly-identical, silently drifting config files
// karma.conf.js AND karma.ci.conf.js with duplicated, diverging settings

Config drift between environments is one of the most preventable sources of confusing 'only fails in CI' bugs.

Coverage Do's and Don'ts

// DO: scope coverage to source files only
preprocessors: { 'src/**/!(*.spec).js': ['coverage'] }

// DON'T: instrument everything, including spec files
preprocessors: { 'src/**/*.js': ['coverage'] }

The !(*.spec) extended glob pattern is the specific fix for the most common coverage misconfiguration.
Instrumenting spec files inflates line counts without adding any meaningful coverage signal.
This single mistake is one of the most frequently repeated ones across real Karma projects.
Double-check any coverage glob pattern change against the generated report immediately, not later.

Do's and Don'ts Cheat Sheet

A rapid-scan comparison across every major area of this course.

Do	Don't
Use `ChromeHeadless` for CI and most local runs	Use a visible browser in CI where no display server exists
Set `singleRun: true` for CI invocations	Leave `singleRun: false` in a CI pipeline
Exclude spec files from coverage instrumentation	Instrument spec files alongside real source files
Add `--no-sandbox` proactively for container-based CI	Wait for a launch failure before adding container-safe flags
Pair a terminal reporter with a file-writing one	Rely on terminal output alone in an automated CI pipeline
Set coverage thresholds near current real coverage	Set an aspirational threshold that fails CI immediately
Mock HTTP calls in Angular service tests	Call a real backend from a unit test
Categorize a failure before debugging deeply	Jump straight to breakpoints without reading the error first

Browser and Launcher Do's and Don'ts

Browser configuration mistakes are usually the very first thing a new team member hits when setting up a project locally, making them worth getting right early.

Do	Don't
Install the matching `karma-*-launcher` package for every browser used	Assume a browser name works without its launcher package installed
Set `CHROME_BIN`/`FIREFOX_BIN` explicitly on unusual environments	Debug launch failures for hours before checking binary paths
Keep a documented, ready-to-use container-safe custom launcher	Improvise container flags under pressure during an incident

Debugging Do's and Don'ts

The habits that separate a fast debugging session from a slow, frustrating one are almost always about approach, not tooling.

Do	Don't
Reproduce a CI-only failure with the exact CI command locally first	Assume every CI-only failure is unreproducible flakiness
Use `fit()`/`fdescribe()` to isolate a failing spec, then remove them	Leave `fit()`/`fdescribe()` committed, silently skipping other specs
Verify source maps work immediately after a build pipeline change	Discover broken source maps only during an urgent debugging session

Common Mistakes

Treating this comparison list as exhaustive instead of a quick-scan starting point before a deeper review.
Applying 'do' practices inconsistently across different projects or team members.
Not revisiting this list periodically as a project's configuration evolves and potentially drifts from these practices.
Skipping the reasoning behind each recommendation and only memorizing the surface-level rule.

Key Takeaways

Config drift, coverage scoping, and container-safe launchers are the highest-impact areas to get right.
Pairing reporters and setting realistic coverage thresholds prevent common CI integration gaps.
Browser/launcher setup mistakes are usually the first friction point for new team members.
Debugging habits (reproducing locally, isolating specs, checking source maps early) matter as much as configuration.

Pro Tip

Turn this lesson's table into an actual pull request checklist template for changes touching karma.conf.js. A five-second glance at a checklist catches far more of these mistakes before merge than relying on memory during a busy review.