tdd

tdd

Overview

Write the test first. Watch it fail. Write minimal code to pass.

Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.

Violating the letter of the rules is violating the spirit of the rules.

The Iron Law

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

Write code before the test? Delete it. Start over. No exceptions.

Red-Green-Refactor

Red: Write a failing test. Verify it fails for the right reason (feature missing, not a typo). One behavior, clear name, real code (no mocks unless unavoidable).

Green: Write the simplest code to pass the test. Do not add features, refactor nearby code, or "improve" beyond what the test requires.

Refactor: Clean up after green only. Remove duplication, improve names, extract helpers. Keep tests green. Don't add behavior.

Repeat with the next failing test for the next feature.

Good test vs bad test

Good:

test('retries failed operations 3 times', async () => {
  let attempts = 0;
  const operation = () => { attempts++; if (attempts < 3) throw new Error('fail'); return 'success'; };
  const result = await retryOperation(operation);
  expect(result).toBe('success');
  expect(attempts).toBe(3);
});

Clear name, tests real behavior, one thing.

Bad:

test('retry works', async () => {
  const mock = jest.fn().mockRejectedValueOnce(new Error()).mockResolvedValueOnce('success');
  await retryOperation(mock);
  expect(mock).toHaveBeenCalledTimes(3);
});

Vague name, tests mock not code.

Example: Bug Fix

Bug: Empty email accepted

// RED: Write failing test
test('rejects empty email', async () => {
  const result = await submitForm({ email: '' });
  expect(result.error).toBe('Email required');
});

// Verify RED: run test, confirm FAIL with "expected 'Email required', got undefined"

// GREEN: Minimal implementation
function submitForm(data) {
  if (!data.email?.trim()) return { error: 'Email required' };
  // ...
}

// Verify GREEN: run test, confirm PASS