Karma Testing Frameworks

What the frameworks Option Actually Does

The frameworks array in karma.conf.js names one or more Karma plugins (installed as karma-<name> npm packages) that Karma should load before running your tests. A framework adapter plugin's job is twofold: inject the testing framework's global functions (describe, it, expect, etc.) into the browser page, and tell Karma how to interpret that framework's results.

This is why frameworks: ['jasmine'] requires both karma-jasmine (the adapter) and jasmine-core (the actual assertion library) to be installed — the adapter is a thin bridge, not the framework itself.

npm install --save-dev karma-jasmine jasmine-core

// karma.conf.js
config.set({
  frameworks: ['jasmine']
});

// Now available globally in every spec file:
describe('math', function() {
  it('adds numbers', function() {
    expect(1 + 2).toBe(3);
  });
});

karma-jasmine is the glue; jasmine-core is what actually provides describe, it, and expect.

Supported Frameworks at a Glance

frameworks: ['jasmine']        // karma-jasmine + jasmine-core
frameworks: ['mocha']          // karma-mocha + mocha (+ karma-chai for assertions)
frameworks: ['qunit']          // karma-qunit + qunit
frameworks: ['jasmine', 'webpack']  // multiple frameworks can be combined

• Jasmine is the most common choice historically, especially in Angular CLI-generated projects.
• Mocha is unopinionated about assertions, so it's almost always paired with Chai or a similar library.
• Some entries in frameworks aren't test frameworks at all — karma-webpack, for example, registers as a framework to hook into the build pipeline.
• You can combine a real test framework with a build-tool framework in the same array.

Framework Adapter Cheat Sheet

What to install for each common choice.

Why Karma Doesn't Use Jest-Style Syntax by Default

Jasmine's describe/it/expect API predates and heavily influenced Jest's own API — which is why the two often look nearly identical in simple examples. The difference is that Jest bundles its own implementation, while Karma always requires an explicit adapter and framework package to provide that syntax.

• Jasmine's matcher names (.toBe(), .toEqual(), .toContain()) map almost directly onto Jest's.
• Mocha provides no assertions at all by default — Chai (or Node's built-in assert) fills that gap.
• Switching frameworks in Karma means reinstalling the adapter and rewriting spec syntax, since describe/it behavior can differ subtly between them.

Choosing a Framework for a New Karma Project

If you're starting a brand-new Karma configuration today (most commonly to match an existing team convention), Jasmine remains the simplest choice: one adapter, one library, built-in assertions, and it matches the historical Angular CLI default almost every legacy project already uses.

Common Mistakes

• Installing karma-jasmine but forgetting jasmine-core, resulting in describe is not defined errors.
• Mixing Jasmine and Mocha syntax in the same spec file after a partial migration.
• Assuming karma-webpack is a testing framework rather than a build-pipeline integration registered as one.
• Not checking which framework an inherited karma.conf.js already uses before writing new specs in a different style.

Key Takeaways

• frameworks in karma.conf.js names Karma plugins that inject test syntax into the browser.
• Jasmine ships built-in assertions; Mocha requires pairing with a library like Chai.
• Some 'frameworks' (like karma-webpack) are build-pipeline integrations, not testing frameworks.
• Jasmine remains the most common default, especially for Angular-originated Karma projects.