Karma Browser Testing

How the browsers Option Works

Each entry in browsers is the name of a launcher configuration — either a built-in one provided by an installed karma-*-launcher package, or a custom one you define yourself under customLaunchers. Karma uses each named launcher to spawn a browser process, point it at the local Karma server, and track its lifecycle.

Because browser names map to launcher plugins, listing a browser Karma has no matching launcher installed for produces an immediate, clear startup error rather than a silent failure.

npm install --save-dev karma-chrome-launcher karma-firefox-launcher

// karma.conf.js
config.set({
  browsers: ['ChromeHeadless', 'FirefoxHeadless']
});

Both launcher packages must be installed for these two browser names to resolve successfully.

Common Built-In Browser Names

Chrome            // visible Chrome window (karma-chrome-launcher)
ChromeHeadless     // headless Chrome, no window
ChromeCanary       // Chrome Canary build
Firefox            // visible Firefox window (karma-firefox-launcher)
FirefoxHeadless    // headless Firefox, no window
Safari             // visible Safari (karma-safari-launcher, macOS only)

• Headless variants avoid opening a visible window, which is essential for CI servers with no display.
• Each browser family needs its own launcher package (karma-chrome-launcher, karma-firefox-launcher, etc.).
• Browser binaries must actually exist on the machine — installing the launcher plugin alone isn't enough.
• Running several browsers at once runs the full suite once per browser, in parallel, by default.

Browser & Launcher Cheat Sheet

Which package to install for each common browser.

How Karma Finds Browser Binaries

Launcher plugins search common install locations for each browser automatically. When a binary isn't in a standard location (common on CI images or custom environments), you can point Karma at it explicitly using an environment variable like CHROME_BIN or FIREFOX_BIN.

# Linux CI example
export CHROME_BIN=/usr/bin/chromium-browser
karma start --single-run --browsers ChromeHeadless

Setting the *_BIN environment variable is the most common fix for 'browser not found' errors in CI.

Trade-offs of Testing Multiple Browsers

Running your suite across several browsers meaningfully increases confidence in cross-browser behavior, but it also increases total run time and resource usage, and multiplies the number of places a flaky test can fail.

• Use a single fast browser (usually ChromeHeadless) for everyday local development.
• Reserve multi-browser runs for CI, pre-release checks, or dedicated cross-browser test jobs.
• Investigate browser-specific failures individually rather than assuming they're flakiness.
• Consider concurrency limits if running many browsers overwhelms CI machine resources.

Common Mistakes

• Listing a browser name with no matching launcher package installed, causing an immediate startup failure.
• Assuming a launcher package alone installs the actual browser binary — it does not.
• Running heavy multi-browser suites locally on every save instead of reserving them for CI.
• Not setting CHROME_BIN/FIREFOX_BIN on CI images where binaries live in non-standard paths.

Key Takeaways

• browsers names launcher configurations, each backed by an installed karma-*-launcher package.
• Headless variants (ChromeHeadless, FirefoxHeadless) are essential for display-less CI environments.
• Browser binaries must exist on the machine; environment variables like CHROME_BIN help Karma find them.
• Running multiple browsers increases confidence but also run time — balance this deliberately.