🛡️ Testing Principles

Why We Really Test

Every developer eventually learns the hard way that "it works on my machine" is not the same as "it works." A test suite is the machine that repeats the boring, careful checking you would never do by hand on every save. But the value goes deeper than catching bugs — a good suite pays you back in four distinct currencies.

• Regression safety. The whole point of a growing codebase is that you keep changing it. Tests are the tripwire that fires the moment a change quietly breaks something three modules away.
• Living documentation. A well-named test reads like a spec: rejects a withdrawal larger than the balance. Unlike a wiki page, it can never drift out of date, because it either passes or it doesn't.
• Design feedback. Code that is painful to test is usually telling you something — too many dependencies, hidden global state, one function doing five jobs. The friction is a design smell you can act on.
• Confidence to refactor. With tests green, you can restructure aggressively and know within seconds whether behavior still holds. Without them, refactoring is a leap in the dark.

💡 Reframe: Tests are not a tax you pay after writing code. They are the feedback loop that lets you write code faster, because you stop re-verifying old behavior by hand.

The Testing Pyramid

Not all tests are equal. They trade off along two axes: speed and isolation versus realism and confidence. The testing pyramid, popularized by Mike Cohn, is a rule of thumb for balancing them: write many small, fast tests at the base, fewer tests that wire components together in the middle, and only a handful of slow, full-system tests at the top.

Why not just write E2E tests for everything, since they're the most realistic? Because they are slow, flaky, and terrible at telling you where a failure is. A red unit test points at one function; a red E2E test could be anything from a CSS change to a down database. This week lives at the base of the pyramid — unit tests — and next lesson's Jest configuration is what makes running hundreds of them a sub-second affair.

FIRST: What Makes a Good Unit Test

A green checkmark is not the goal — a trustworthy green checkmark is. The FIRST acronym is a checklist for whether a unit test earns its place in the suite.

Two of these break most often in practice, so let's make them concrete.

Isolated & Repeatable in code

// ❌ Not repeatable: the assertion depends on today's date
test('greeting mentions the year', () => {
  expect(buildGreeting()).toContain('2026'); // passes only in 2026
});

// ✅ Repeatable: freeze the clock so the test controls time
test('greeting mentions the current year', () => {
  jest.useFakeTimers().setSystemTime(new Date('2030-01-01'));
  expect(buildGreeting()).toContain('2030');
  jest.useRealTimers(); // restore, so later tests stay isolated
});

// ❌ Not isolated: tests share one mutable array, so order matters
const users = [];
test('adds a user', () => {
  users.push({ name: 'Ada' });
  expect(users).toHaveLength(1); // breaks if another test ran first
});

// ✅ Isolated: build fresh state inside each test (or a beforeEach)
test('adds a user', () => {
  const users = [];
  users.push({ name: 'Ada' });
  expect(users).toHaveLength(1);
});

Test-Driven Development

Test-driven development (TDD) inverts the usual order: you write a failing test first, then just enough code to pass it, then clean up. It sounds backwards until you try it — writing the test first forces you to design the interface from the caller's point of view before you're distracted by the implementation.

1. Red. Write a small test for behavior that doesn't exist yet. Run it and watch it fail — this proves the test can fail, so a later pass means something.
2. Green. Write the simplest code that makes it pass. Ugly is fine here; correctness first.
3. Refactor. Now improve the code — rename, extract, simplify — with the safety net of a passing test underneath you.

A tiny TDD loop

Say we need isValidZip(str) that accepts a US 5-digit ZIP. We start with the test that doesn't compile yet:

// zip.test.js — RED
const { isValidZip } = require('./zip');

test('accepts a plain 5-digit zip', () => {
  expect(isValidZip('90210')).toBe(true);
});
test('rejects anything that is not exactly 5 digits', () => {
  expect(isValidZip('9021')).toBe(false);   // too short
  expect(isValidZip('902100')).toBe(false); // too long
  expect(isValidZip('9021a')).toBe(false);  // not digits
});

// zip.js — GREEN: the simplest thing that passes
function isValidZip(str) {
  return /^\d{5}$/.test(str);
}
module.exports = { isValidZip };

The regex passes both tests immediately, so there's little to refactor here — but the loop is the point. Each new requirement (ZIP+4? leading-zero ZIPs like '01234'?) becomes a new red test before a line of implementation.

The Test Doubles Family

To keep a unit test fast and isolated, you often have to replace a real dependency — a database, a payment gateway, the network — with a stand-in. Gerard Meszaros called these stand-ins test doubles (like a stunt double in film). There are five, and using the right name for the right job keeps your tests honest.

Jest gives you tools that cover all five — jest.fn() for stubs and mocks, jest.spyOn() for spies — and you'll write plain objects and classes for dummies and fakes. Here are the two you'll reach for most:

// STUB — jest.fn() returning a canned value
const db = { getUser: jest.fn().mockReturnValue({ id: 1, name: 'Ada' }) };
const service = new ProfileService(db);
expect(service.displayName(1)).toBe('Ada'); // db.getUser is stubbed

// SPY — watch a real method without replacing it
const logger = { warn(msg) { /* real impl */ } };
const spy = jest.spyOn(logger, 'warn');
chargeCard(logger, -5);            // should log a warning
expect(spy).toHaveBeenCalledTimes(1);
spy.mockRestore();                 // put the real method back

// FAKE — a working in-memory stand-in for a real repository
class FakeUserRepo {
  #store = new Map();
  async save(user) { this.#store.set(user.id, user); return user; }
  async findById(id) { return this.#store.get(id) ?? null; }
}

test('updateName persists the change', async () => {
  const repo = new FakeUserRepo();
  await repo.save({ id: '1', name: 'Old' });
  const service = new UserService(repo);

  await service.updateName('1', 'New');

  expect((await repo.findById('1')).name).toBe('New');
});

Practice & Quiz

// password.test.js
const { isStrongPassword } = require('./password');

test.each([
  ['abc12', false],        // too short
  ['abcdefgh', false],     // no digit
  ['12345678', false],     // no letter
  ['abcd1234', true],      // long enough, has both
])('isStrongPassword(%s) === %s', (pwd, expected) => {
  expect(isStrongPassword(pwd)).toBe(expected);
});

// password.js
function isStrongPassword(pwd) {
  return pwd.length >= 8 && /[a-zA-Z]/.test(pwd) && /\d/.test(pwd);
}
module.exports = { isStrongPassword };

Best Practices & Pitfalls

✅ Do

• Weight your suite toward fast, isolated unit tests; add integration and E2E only where they earn their cost
• Build fresh state inside each test (or in beforeEach) so tests stay isolated and order-independent
• Give each test one reason to fail and a name that reads like a sentence
• Freeze the clock and control randomness so tests are repeatable
• Reach for the cheapest double that does the job — often a fake beats a pile of mocks

❌ Don't

• Chase 100% coverage by testing trivial getters — coverage is a hint, not a goal (more on this next lesson)
• Let tests share mutable module-level state
• Assert on the clock, Math.random(), or a live external API in a unit test
• Mock so heavily that the test only proves your mocks were called

Summary

📚 Additional Resources

• Jest — Getting Started
• Martin Fowler — The Practical Test Pyramid
• Martin Fowler — Test Double
• Kent C. Dodds — Write Tests. Not Too Many. Mostly Integration.

🚀 What's Next?

You know what to test and why. Next we make running those tests effortless: Jest Configuration — the jest.config.js options that control the test environment, coverage thresholds, and setup files (and where the Vite-native Vitest fits in).