Testing in JavaScript

Unit tests, integration tests, mocking, and the tools — Jest, Vitest, and the testing-library approach explained plainly.

What it is, in plain English: Testing in JavaScript means writing code that automatically checks whether your code works. A unit test checks one function in isolation. An integration test checks multiple pieces working together. Jest and Vitest are the most popular test runners — they find test files, run them, and report which assertions passed or failed. The testing-library approach tests what users see and do rather than implementation details.

Where this bites you

Assigning a mock to a global, such as global.fetch = vi.fn()..., replaces it for every test that runs afterwards in that file, not just the current one. A completely unrelated test then fails, but only when it runs after the mocking test, and passes when you run it alone. It's one of the most confusing failures to debug, because the broken test's own code is fine.

// shown with Node's built-in runner (node --test); Vitest and Jest behave the same way
import { test } from "node:test";
import assert from "node:assert/strict";

async function getUser(id) {
  const res = await fetch(`https://api.example.com/users/${id}`);
  if (!res.ok) throw new Error("User not found");
  return res.json();
}

test("getUser throws on 404", async () => {
  globalThis.fetch = async () => ({ ok: false, status: 404 });   // replaced... never put back
  await assert.rejects(getUser(999), /User not found/);
});

test("reads settings from a data: URL", async () => {             // an unrelated test
  const res = await fetch('data:application/json,{"theme":"dark"}');
  assert.equal((await res.json()).theme, "dark");
});
// ok 1 - getUser throws on 404
// not ok 2 - reads settings from a data: URL     error: 'res.json is not a function'
// (run test 2 on its own and it passes)

Writing code that checks your code

Testing means writing a second program whose job is to check that your first program works. Every time you add a feature or fix a bug, you run the tests — they tell you instantly if anything broke. This is how professional developers ship code with confidence.

What a test looks like

// Using Jest or Vitest (same syntax):
import { describe, test, expect } from "vitest";
import { add, divide } from "./math.js";

describe("math utilities", () => {

  test("add returns the sum", () => {
    expect(add(2, 3)).toBe(5);       // 2+3 should equal 5
    expect(add(-1, 1)).toBe(0);      // -1+1 should equal 0
    expect(add(0, 0)).toBe(0);
  });

  test("divide returns correct result", () => {
    expect(divide(10, 2)).toBe(5);
    expect(divide(7, 2)).toBe(3.5);
  });

  test("divide throws on zero divisor", () => {
    expect(() => divide(10, 0)).toThrow("Cannot divide by zero");
  });

});

The most useful matchers

// Equality
expect(value).toBe(5);           // strict equality (===)
expect(obj).toEqual({a:1});      // deep equality (nested objects)
expect(arr).toStrictEqual([1,2]); // like toEqual, also checks undefined properties

// Truthiness
expect(value).toBeTruthy();
expect(value).toBeFalsy();
expect(value).toBeNull();
expect(value).toBeUndefined();
expect(value).toBeDefined();

// Numbers
expect(0.1 + 0.2).toBeCloseTo(0.3);  // floating-point safe!
expect(5).toBeGreaterThan(3);
expect(5).toBeLessThanOrEqual(5);

// Strings and arrays
expect("hello world").toContain("world");
expect([1, 2, 3]).toContain(2);
expect([1, 2, 3]).toHaveLength(3);

// Objects
expect(obj).toHaveProperty("name");
expect(obj).toHaveProperty("address.city", "Mumbai");

// Errors
expect(() => badFn()).toThrow();
expect(() => badFn()).toThrow(TypeError);
expect(() => badFn()).toThrow("specific message");

Setup and teardown

import { beforeEach, afterEach, describe, test, expect } from "vitest";

describe("user store", () => {
  let store;

  beforeEach(() => {
    // Runs before each test — set up fresh state:
    store = new UserStore();
    store.add({ id: 1, name: "Alice" });
  });

  afterEach(() => {
    // Runs after each test — clean up:
    store.clear();
  });

  test("findById returns the user", () => {
    expect(store.findById(1).name).toBe("Alice");
  });

  test("findById returns null for missing id", () => {
    expect(store.findById(99)).toBeNull();
  });
});

Try It Yourself

// You can write your own test runner in 10 lines of JS
// This is exactly what Jest/Vitest do under the hood

function test(description, fn) {
  try {
    fn();
    console.log(`  ✓  ${description}`);
  } catch (e) {
    console.log(`  ✗  ${description}`);
    console.log(`     ${e.message}`);
  }
}

// A function we want to test:
function divide(a, b) {
  if (b === 0) throw new Error("Cannot divide by zero");
  return a / b;
}

// Tests:
console.log("divide():");
test("10 / 2 = 5",           () => expect(divide(10, 2)).toBe(5));
test("7 / 2 = 3.5",          () => expect(divide(7, 2)).toBe(3.5));
test("throws on divide by 0", () => expect(() => divide(5, 0)).toThrow());
test("intentional fail",      () => expect(divide(10, 2)).toBe(6));  // will fail

// Testing arrays and objects:
function getUser(id) {
  return { id, name: "Alice", role: "admin" };
}

console.log("\ngetUser():");
test("returns correct shape", () =>
  expect(getUser(1)).toEqual({ id: 1, name: "Alice", role: "admin" }));
test("id matches",            () =>
  expect(getUser(42).id).toBe(42));

Mocking, spies, and async tests

Mocking — replace real implementations with fakes

import { vi, test, expect } from "vitest";

// Mock a module:
vi.mock("./emailService.js", () => ({
  sendEmail: vi.fn().mockResolvedValue({ success: true }),
}));

// Mock a function:
const fetchUser = vi.fn().mockResolvedValue({ id: 1, name: "Alice" });

test("sends welcome email after registration", async () => {
  const { sendEmail } = await import("./emailService.js");

  await registerUser({ name: "Bob", email: "bob@example.com" });

  // Assert the mock was called correctly:
  expect(sendEmail).toHaveBeenCalledOnce();
  expect(sendEmail).toHaveBeenCalledWith({
    to: "bob@example.com",
    subject: "Welcome!",
  });
});

Testing async code

// Always return or await async tests:
test("fetches user from API", async () => {
  // Option 1: mock fetch globally
  global.fetch = vi.fn().mockResolvedValue({
    ok: true,
    json: async () => ({ id: 1, name: "Alice" }),
  });

  const user = await getUser(1);
  expect(user.name).toBe("Alice");
});

// Testing that a promise rejects:
test("throws on 404", async () => {
  global.fetch = vi.fn().mockResolvedValue({
    ok: false,
    status: 404,
  });
  await expect(getUser(999)).rejects.toThrow("User not found");
});

The two async tests above overwrite global.fetch in exactly this way. Save the original and restore it after every test, as below. In Vitest you can also use vi.stubGlobal("fetch", ...) together with vi.unstubAllGlobals() in afterEach, which does the bookkeeping for you:

import { test, afterEach } from "node:test";
import assert from "node:assert/strict";

const realFetch = globalThis.fetch;
afterEach(() => { globalThis.fetch = realFetch; });               // undo every test's replacement

test("getUser throws on 404", async () => {
  globalThis.fetch = async () => ({ ok: false, status: 404 });
  await assert.rejects(getUser(999), /User not found/);
});

test("reads settings from a data: URL", async () => {
  const res = await fetch('data:application/json,{"theme":"dark"}');
  assert.equal((await res.json()).theme, "dark");
});
// ok 1 - getUser throws on 404
// ok 2 - reads settings from a data: URL

Vitest vs Jest — choose based on your build tool

// Jest — older, more ecosystem support, built-in mocking
// Works with any setup; default for Create React App
// npm install --save-dev jest @jest/globals

// Vitest — modern, works natively with Vite, much faster
// Same API as Jest — easy migration
// npm install --save-dev vitest

// vitest.config.ts:
// export default defineConfig({ test: { globals: true, environment: "jsdom" } })

// Run:
// jest              → jest
// npx vitest run    → vitest (CI)
// npx vitest        → vitest (watch mode)
// npx vitest --coverage  → coverage report

Testing DOM with jsdom and testing-library

import { render, screen, fireEvent } from "@testing-library/react";
import { test, expect } from "vitest";
import Counter from "./Counter";

test("counter increments when button is clicked", () => {
  render(<Counter />);

  // Query by what the USER sees, not by class/id:
  const button = screen.getByRole("button", { name: /increment/i });
  const count  = screen.getByText("0");

  fireEvent.click(button);

  expect(screen.getByText("1")).toBeInTheDocument();
});

Coverage, TDD, and the testing pyramid

Coverage — measuring what's tested

// npx vitest --coverage  (uses c8 or v8 under the hood)
// Reports:
//   Statements: % of statements executed
//   Branches:   % of if/else branches taken
//   Functions:  % of functions called
//   Lines:      % of lines executed

// 100% coverage doesn't mean bug-free — it means every line ran,
// not that every edge case was tested.
// Aim for high branch coverage — that's where bugs hide.

Test-Driven Development (TDD)

// Red → Green → Refactor cycle:
// 1. Write a FAILING test for the feature (Red)
// 2. Write the MINIMUM code to make it pass (Green)
// 3. Refactor the code while keeping tests green

// Step 1: Red (test exists, function doesn't):
test("isPalindrome returns true for 'racecar'", () => {
  expect(isPalindrome("racecar")).toBe(true);  // fails: isPalindrome not defined
});

// Step 2: Green (minimum implementation):
function isPalindrome(str) {
  return str === str.split("").reverse().join("");
}

// Step 3: Refactor (handle edge cases):
function isPalindrome(str) {
  const clean = str.toLowerCase().replace(/[^a-z0-9]/g, "");
  return clean === clean.split("").reverse().join("");
}

The testing pyramid

A healthy test suite has more unit tests than integration tests, and more integration tests than end-to-end tests:

// Unit tests (most — fast, isolated, cheap):
//   Test one function/class in isolation
//   Mock all external dependencies
//   Run in milliseconds

// Integration tests (some — slower, realistic):
//   Test multiple units working together
//   May use a real database (test DB) or HTTP server
//   Run in seconds

// End-to-end tests (few — slowest, most realistic):
//   Playwright / Cypress — real browser, real server
//   Test full user flows
//   Run in minutes

Official Sources

The Codex links only to official documentation and the ECMAScript specification. No third-party tutorials.