Your First Karma Test

This lesson walks through writing your very first Karma test from an empty project: creating a function, writing a Jasmine spec, running Karma, and reading the terminal output when the test passes and when it fails.

Writing a Function to Test

A good first test targets a small, pure function with no dependencies, so there's nothing to mock and nothing asynchronous to manage. Below, sum.js exports a plain addition function, loaded directly in the browser as a global script (no bundler yet), and the companion spec file checks its behavior with Jasmine's expect().

Karma serves both files to the browser based on the files array in karma.conf.js; the browser then runs whatever Jasmine finds inside the spec file.

// sum.js
function sum(a, b) {
  return a + b;
}

// sum.spec.js
describe('sum()', function() {
  it('adds 1 + 2 to equal 3', function() {
    expect(sum(1, 2)).toBe(3);
  });
});

No imports are needed here because both files are loaded as plain scripts into the same browser page by Karma.

Configuring and Running the Test

// karma.conf.js
module.exports = function(config) {
  config.set({
    frameworks: ['jasmine'],
    files: ['sum.js', 'sum.spec.js'],
    browsers: ['ChromeHeadless'],
    singleRun: true
  });
};

npx karma start

files must list source files before spec files if specs reference globals directly (order matters for plain scripts).
ChromeHeadless runs Chrome without opening a visible window — ideal for terminals and CI.
singleRun: true makes Karma exit with a pass/fail exit code instead of staying open.
Karma prints a summary line per browser, e.g. Chrome Headless: Executed 1 of 1 SUCCESS.

First Test Cheat Sheet

The minimum pieces every first Karma test needs.

Piece	Example
Source function	`function sum(a, b) { return a + b; }`
Group tests	`describe('sum()', function() { ... });`
Define a test	`it('description', function() { ... });`
Assert the result	`expect(sum(1, 2)).toBe(3);`
List files to load	`files: ['sum.js', 'sum.spec.js']`
Run it	`npx karma start --single-run`

Reading Karma's Terminal Output

A successful run prints a compact summary per browser and per spec. Seeing a failure early is valuable — it teaches you how to read Karma's output before you're debugging something you actually care about.

# Passing run
Chrome Headless 120.0.0 (Mac OS 10.15.7): Executed 1 of 1 SUCCESS (0.003 secs / 0.001 secs)
TOTAL: 1 SUCCESS

# Failing run (expected wrong value)
Chrome Headless 120.0.0 (Mac OS 10.15.7) sum() adds 1 + 2 to equal 3 FAILED
  Expected 3 to be 4.
TOTAL: 1 FAILED, 0 SUCCESS

Karma reports the browser name and version alongside every result, since the same suite can run in several browsers at once.

Spec File Naming Conventions

Karma has no built-in convention for spec file names the way Jest does — everything is controlled explicitly through the files glob patterns in karma.conf.js. That said, *.spec.js is the overwhelming community convention, especially in Angular projects.

*.spec.js — the near-universal convention for Jasmine/Mocha spec files.
*.test.js — also seen, especially in projects migrated from Jest-style tooling.
Glob patterns like src/**/*.spec.js let specs live next to the code they test.
Whatever convention you choose, keep the files glob in karma.conf.js consistent with it.

Common Mistakes

Listing files in the wrong order when using plain scripts, so a spec runs before its source file loads.
Forgetting to install karma-chrome-launcher and getting a 'no such browser' launch error.
Testing implementation details instead of the function's observable behavior.
Not running the test at all before moving on — always confirm it actually executes and passes.

Key Takeaways

Start with a small, pure function; it's the easiest thing to test with no setup overhead.
Jasmine's describe/it/expect structure is nearly identical to what most other JS test frameworks use.
Karma's files array controls exactly which scripts are loaded into the browser, and in what order.
Karma's terminal output always identifies which browser produced each result.

Pro Tip

Intentionally break your first test (change the expected value) before moving on. Learning to read a Karma failure calmly, on a test you already understand, pays off the first time a real failure looks confusing.