🔬 Writing Unit Tests

The Art of Unit Testing

Writing unit tests is a bit like being a detective. You imagine every scenario in which your code might misbehave, then set up a controlled experiment to see whether it actually does. But great tests do more than catch bugs — they document behavior, they enable fearless refactoring, and they define the shape of the code they cover.

A unit is the smallest testable slice of your program: usually a single function or a single class method. The defining trait of a unit test is isolation — it exercises that one piece with everything else swapped out for predictable stand-ins.

What Makes a Good Test? The FIRST Principles

The qualities of a trustworthy unit test spell the handy acronym FIRST. Keep these five in mind and most testing problems disappear.

Bad vs. good, side by side

// ❌ Bad: slow, hits a real API, not isolated or repeatable
test('user service fetches data from API', async () => {
  const userService = new UserService();
  const user = await userService.getUser(1); // real network call!
  expect(user.name).toBe('John Doe');         // breaks when the API changes
});

// ✅ Good: fast, isolated, repeatable
test('user service returns the user from its data source', async () => {
  const mockApi = {
    fetchUser: jest.fn().mockResolvedValue({ id: 1, name: 'John Doe' }),
  };
  const userService = new UserService(mockApi);

  const user = await userService.getUser(1);

  expect(user.name).toBe('John Doe');
  expect(mockApi.fetchUser).toHaveBeenCalledWith(1);
});

The good version injects a fake API. It never touches the network, so it's fast and repeatable, and it also verifies the collaboration — that fetchUser was called with the right id.

Anatomy of a Unit Test

You met Arrange-Act-Assert in the last lesson. It's worth internalizing because it makes any test readable at a glance. Arrange the world, Act by calling the unit, Assert the outcome.

describe('ShoppingCart', () => {
  describe('addItem', () => {
    it('adds an item to the cart', () => {
      // Arrange
      const cart = new ShoppingCart();
      const item = { id: 1, name: 'Book', price: 29.99 };

      // Act
      cart.addItem(item);

      // Assert
      expect(cart.items).toHaveLength(1);
      expect(cart.items[0]).toEqual(item);
    });

    it('increments quantity when adding an existing item', () => {
      const cart = new ShoppingCart();
      const item = { id: 1, name: 'Book', price: 29.99 };

      cart.addItem(item, 1);
      cart.addItem(item, 2);

      expect(cart.items).toHaveLength(1);
      expect(cart.items[0].quantity).toBe(3);
    });
  });
});

Testing Pure Functions

A pure function returns the same output for the same input and has no side effects. These are the easiest and most rewarding things to test — no setup, no mocks, just input in and output out.

// discount.js
export function calculateDiscount(price, discountPercentage) {
  if (price < 0 || discountPercentage < 0 || discountPercentage > 100) {
    throw new Error('Invalid input');
  }
  const discount = price * (discountPercentage / 100);
  return Number((price - discount).toFixed(2)); // round to cents
}

// discount.test.js
import { calculateDiscount } from './discount';

describe('calculateDiscount', () => {
  it('applies a percentage discount', () => {
    expect(calculateDiscount(100, 20)).toBe(80);
    expect(calculateDiscount(50, 10)).toBe(45);
  });

  it('handles the 0% and 100% boundaries', () => {
    expect(calculateDiscount(100, 0)).toBe(100);
    expect(calculateDiscount(100, 100)).toBe(0);
  });

  it('rejects invalid input', () => {
    expect(() => calculateDiscount(-50, 10)).toThrow('Invalid input');
    expect(() => calculateDiscount(100, 150)).toThrow('Invalid input');
  });
});

Table-driven tests with test.each

When a function has many input/output pairs, don't copy-paste a dozen tests. Jest's test.each runs one test body over a table of cases and gives each a descriptive name:

describe('calculateDiscount (table-driven)', () => {
  test.each([
    { price: 100, discount: 20, expected: 80 },
    { price: 50,  discount: 10, expected: 45 },
    { price: 200, discount: 15, expected: 170 },
    { price: 100, discount: 0,  expected: 100 },
    { price: 100, discount: 100, expected: 0 },
  ])('$price at $discount% → $expected', ({ price, discount, expected }) => {
    expect(calculateDiscount(price, discount)).toBe(expected);
  });
});

Testing Classes and Objects

When testing a class, aim at its public interface and observable behavior — not its private fields. If you test what the class does rather than how, you can refactor the internals freely without rewriting tests.

// bankAccount.js
export class BankAccount {
  constructor(initialBalance = 0) {
    this._balance = initialBalance;
    this._transactions = [];
  }

  get balance() {
    return this._balance;
  }

  deposit(amount) {
    if (amount <= 0) throw new Error('Deposit amount must be positive');
    this._balance += amount;
    this._transactions.push({ type: 'deposit', amount, date: new Date() });
    return this._balance;
  }

  withdraw(amount) {
    if (amount <= 0) throw new Error('Withdrawal amount must be positive');
    if (amount > this._balance) throw new Error('Insufficient funds');
    this._balance -= amount;
    this._transactions.push({ type: 'withdrawal', amount, date: new Date() });
    return this._balance;
  }

  getTransactionHistory() {
    return [...this._transactions]; // return a copy, not the internal array
  }
}

// bankAccount.test.js
import { BankAccount } from './bankAccount';

describe('BankAccount', () => {
  let account;

  // beforeEach gives every test a fresh, identical starting point.
  beforeEach(() => {
    account = new BankAccount(100);
  });

  describe('deposit', () => {
    it('increases the balance', () => {
      account.deposit(50);
      expect(account.balance).toBe(150);
    });

    it('records the transaction', () => {
      account.deposit(50);
      const [tx] = account.getTransactionHistory();
      expect(tx).toMatchObject({ type: 'deposit', amount: 50, date: expect.any(Date) });
    });

    it('rejects a non-positive amount', () => {
      expect(() => account.deposit(0)).toThrow('Deposit amount must be positive');
      expect(() => account.deposit(-50)).toThrow('Deposit amount must be positive');
    });
  });

  describe('withdraw', () => {
    it('decreases the balance', () => {
      account.withdraw(30);
      expect(account.balance).toBe(70);
    });

    it('rejects an overdraft', () => {
      expect(() => account.withdraw(150)).toThrow('Insufficient funds');
    });
  });

  describe('getTransactionHistory', () => {
    it('returns a copy, so callers cannot mutate internal state', () => {
      account.deposit(50);
      const history = account.getTransactionHistory();
      history.push({ type: 'fake', amount: 1000 }); // tamper with the copy
      expect(account.getTransactionHistory()).toHaveLength(1); // original unchanged
    });
  });
});

Mocking Dependencies

Isolation is the heart of unit testing, and mocking is how you achieve it. A mock is a stand-in — like a stunt double in a movie — that you control completely. It lets a test run without the real database, network, clock, or random-number generator.

Mock functions with jest.fn()

const mockCallback = jest.fn();

mockCallback('first');
mockCallback('second');

expect(mockCallback).toHaveBeenCalled();
expect(mockCallback).toHaveBeenCalledTimes(2);
expect(mockCallback).toHaveBeenCalledWith('first');

// Program return values:
const mockAdd = jest.fn((a, b) => a + b);   // custom implementation
const mockFetch = jest.fn().mockResolvedValue({ data: 'ok' });   // async success
const mockFail  = jest.fn().mockRejectedValue(new Error('down')); // async failure

Injecting a mock into the unit

The cleanest, most testable design passes dependencies into a class (dependency injection). Then a test simply hands over a mock:

// userService.js
export class UserService {
  constructor(apiClient) {
    this.apiClient = apiClient;
    this.cache = new Map();
  }

  async getUser(id) {
    if (this.cache.has(id)) return this.cache.get(id); // serve from cache
    const user = await this.apiClient.fetchUser(id);
    this.cache.set(id, user);
    return user;
  }
}

// userService.test.js
import { UserService } from './userService';

describe('UserService', () => {
  let service;
  let mockApiClient;

  beforeEach(() => {
    mockApiClient = { fetchUser: jest.fn() };
    service = new UserService(mockApiClient);
  });

  it('fetches a user from the API', async () => {
    const mockUser = { id: 1, name: 'John Doe' };
    mockApiClient.fetchUser.mockResolvedValue(mockUser);

    const user = await service.getUser(1);

    expect(user).toEqual(mockUser);
    expect(mockApiClient.fetchUser).toHaveBeenCalledWith(1);
  });

  it('caches the user after the first fetch', async () => {
    mockApiClient.fetchUser.mockResolvedValue({ id: 1, name: 'John Doe' });

    await service.getUser(1);
    await service.getUser(1); // second call should hit the cache

    expect(mockApiClient.fetchUser).toHaveBeenCalledTimes(1);
  });

  it('propagates API errors', async () => {
    mockApiClient.fetchUser.mockRejectedValue(new Error('API Error'));
    await expect(service.getUser(1)).rejects.toThrow('API Error');
  });
});

Testing Edge & Error Cases

The happy path is the easy 20%. Bugs live at the boundaries: empty strings, zero, negative numbers, the very first and very last element, and every way input can be wrong. Good tests go looking for trouble there.

// truncate.js
export function truncate(str, maxLength, suffix = '...') {
  if (typeof str !== 'string') {
    throw new TypeError('Input must be a string');
  }
  if (typeof maxLength !== 'number' || maxLength < 0) {
    throw new TypeError('Max length must be a non-negative number');
  }
  if (str.length <= maxLength) return str;
  if (maxLength === 0) return '';
  const room = maxLength - suffix.length;
  if (room <= 0) return suffix.substring(0, maxLength);
  return str.substring(0, room) + suffix;
}

// truncate.test.js
import { truncate } from './truncate';

describe('truncate', () => {
  // Normal cases
  it('truncates a long string and adds the suffix', () => {
    expect(truncate('Hello World', 8)).toBe('Hello...');
  });
  it('leaves a short string untouched', () => {
    expect(truncate('Hello', 10)).toBe('Hello');
  });

  // Edge cases
  it('handles an empty string', () => {
    expect(truncate('', 5)).toBe('');
  });
  it('handles a zero max length', () => {
    expect(truncate('Hello', 0)).toBe('');
  });
  it('handles a max length shorter than the suffix', () => {
    expect(truncate('Hello World', 2)).toBe('..');
  });
  it('respects a custom suffix', () => {
    expect(truncate('Hello World', 8, '…')).toBe('Hello W…');
  });

  // Error cases
  it('throws for non-string input', () => {
    expect(() => truncate(123, 5)).toThrow(TypeError);
    expect(() => truncate(null, 5)).toThrow(TypeError);
  });
  it('throws for an invalid max length', () => {
    expect(() => truncate('Hello', -1)).toThrow(TypeError);
  });
});

Practice & Quiz

// stack.js
export class Stack {
  #items = [];
  push(x) { this.#items.push(x); return this.size; }
  pop() {
    if (this.#items.length === 0) throw new Error('Stack is empty');
    return this.#items.pop();
  }
  get size() { return this.#items.length; }
}

import { Stack } from './stack';

describe('Stack', () => {
  let stack;
  beforeEach(() => { stack = new Stack(); });

  it('starts empty', () => {
    expect(stack.size).toBe(0);
  });

  it('pushes and reports the new size', () => {
    expect(stack.push('a')).toBe(1);
    expect(stack.push('b')).toBe(2);
  });

  it('pops in last-in-first-out order', () => {
    stack.push('a');
    stack.push('b');
    expect(stack.pop()).toBe('b');
    expect(stack.pop()).toBe('a');
    expect(stack.size).toBe(0);
  });

  it('throws when popping an empty stack', () => {
    expect(() => stack.pop()).toThrow('Stack is empty');
  });
});

// notifier.js
export class Notifier {
  constructor(emailClient) { this.emailClient = emailClient; }
  notify(user, message) {
    return this.emailClient.send(user.email, message);
  }
}

import { Notifier } from './notifier';

test('notify sends an email to the user', () => {
  const emailClient = { send: jest.fn().mockReturnValue(true) };
  const notifier = new Notifier(emailClient);

  const result = notifier.notify({ email: 'a@b.com' }, 'Hi');

  expect(result).toBe(true);
  expect(emailClient.send).toHaveBeenCalledWith('a@b.com', 'Hi');
  expect(emailClient.send).toHaveBeenCalledTimes(1);
});

Best Practices & Pitfalls

✅ Do

• Write descriptive names: 'returns null when the user is not found'
• Test one behavior per test, and follow Arrange-Act-Assert
• Test public behavior; treat private fields as invisible
• Cover the happy path and edge/error cases
• Use test.each for repetitive input/output tables
• Mock only external, slow, or nondeterministic dependencies

❌ Don't

• Share mutable state between tests (leaked counter++ bugs)
• Assert on private internals like service._cache
• Cram five behaviors into one "kitchen-sink" test
• Mock everything until the test proves nothing real
• Test the framework — trust that React or Jest itself works

// ❌ Fragile: relies on running in a specific order
let counter = 0;
test('a', () => { counter++; expect(counter).toBe(1); });
test('b', () => { counter++; expect(counter).toBe(2); }); // breaks if reordered

// ✅ Independent: each test owns its state
test('a', () => { let n = 0; expect(++n).toBe(1); });
test('b', () => { let n = 0; expect(++n).toBe(1); });

Summary

📚 Additional Resources

• Jest — Setup and Teardown
• Jest — Mock Functions
• Jest — test.each
• MDN — Pure function

🚀 What's Next?

So far we've written code first and tested it after. The next lesson flips that around: with Test-Driven Development you write the failing test first and let it drive the design, cycling through Red, Green, Refactor.