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.

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

// 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");
});

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.