Testing your code

Why automated tests?

Checking by hand ("I clicked around and it looked fine") does not scale. When you change one function in a 50,000-line app, you cannot re-check everything by hand. An automated test suite re-checks hundreds of behaviours in seconds, every time, and tells you exactly what broke. Every task in this course is checked by small automated tests.

Kinds of tests

The "testing pyramid" advice: many fast unit tests, fewer integration tests, and a small number of E2E tests for the most important user journeys (sign up, checkout).

A first test with Vitest (Jest looks almost the same)

// price.js
export function applyDiscount(price, percent) {
  if (percent < 0 || percent > 100) throw new RangeError('Bad percent');
  return Math.round(price * (1 - percent / 100));
}

// price.test.js
import { describe, it, expect } from 'vitest';
import { applyDiscount } from './price.js';

describe('applyDiscount', () => {
  it('takes the percentage off', () => {
    expect(applyDiscount(1000, 10)).toBe(900);
  });
  it('rounds to the nearest rupee', () => {
    expect(applyDiscount(999, 15)).toBe(849);
  });
  it('rejects impossible percentages', () => {
    expect(() => applyDiscount(100, 120)).toThrow(RangeError);
  });
});

npm install --save-dev vitest
npx vitest run

Arrange, act, assert

A clear test has three parts: arrange (set up the inputs), act (call the code), assert (check the result). One behaviour per test, with a name that reads like a sentence: "rejects impossible percentages". When it fails, the name tells you what broke.

What to test: edge cases

• The normal case (₹1000 with 10%).
• Boundaries: 0, 100, exactly at a limit (₹499 for free delivery).
• Empty inputs: [], '', no arguments.
• Bad inputs: negative numbers, wrong types, null.
• Rounding and money: 0.1 + 0.2 style surprises.

node:test, built into Node

import { test } from 'node:test';
import assert from 'node:assert/strict';
import { applyDiscount } from './price.js';

test('takes 10% off', () => {
  assert.equal(applyDiscount(1000, 10), 900);
});
// run with: node --test

TDD and coverage

Test-driven development (TDD) means writing a failing test first, then the simplest code that passes, then cleaning up (red, green, refactor). Code coverage tools report which lines your tests ran. High coverage is a good sign but not proof: a test can run a line without checking that its result is right.