Writing the First Failing Test — Choosing Where to Start

1// Building a Roman numeral converter with TDD
2// WRONG first test — too ambitious:
3test('converts 2024 to MMXXIV', () => {
4  expect(toRoman(2024)).toBe('MMXXIV');
5});
6// This requires implementing I, V, X, L, C, D, M all at once
7
8// CORRECT first test — simplest degenerate case:
9test('converts 1 to I', () => {
10  expect(toRoman(1)).toBe('I');
11});
12// Implementation: return 'I';
13// Done in 30 seconds, cycle complete
14
15// Second test — next simplest:
16test('converts 2 to II', () => {
17  expect(toRoman(2)).toBe('II');
18});
19// Now 'return I' fails — we must think about repetition
20
21// More examples of simplest degenerate cases:
22
23// For a sorting algorithm:
24test('returns empty array for empty input', () => {
25  expect(sortNumbers([])).toEqual([]);
26});
27
28// For a string parser:
29test('returns empty list for empty string', () => {
30  expect(parseCSV('')).toEqual([]);
31});
32
33// For a tree traversal:
34test('returns empty list for null root', () => {
35  expect(traverse(null)).toEqual([]);
36});
37
38// For a calculator:
39test('returns 0 for addition of two zeros', () => {
40  expect(add(0, 0)).toBe(0);
41});
42
43// The degenerate case is usually:
44// - Empty input (empty string, empty array, null)
45// - Boundary value (0, 1, -1)
46// - The simplest non-trivial input (1 item, single character)
47// It should take < 30 seconds to implement

1// Without triangulation, the first two tests can pass with hardcoded values:
2test('converts 1 to I', () => { expect(toRoman(1)).toBe('I'); });
3// Green: return 'I';
4
5// With only one test, we cannot tell if the implementation is general.
6// Triangulation: add a test with a DIFFERENT input
7test('converts 2 to II', () => { expect(toRoman(2)).toBe('II'); });
8// FAIL — 'I' !== 'II'
9// Now we MUST write a general implementation
10
11export function toRoman(n: number): string {
12  return 'I'.repeat(n); // general! passes both tests
13}
14
15// Third triangle point:
16test('converts 4 to IV', () => { expect(toRoman(4)).toBe('IV'); });
17// FAIL — 'IIII' !== 'IV'
18// Forces us to handle subtractive notation
19
20export function toRoman(n: number): string {
21  const values = [1000, 900, 500, 400, 100, 90, 50, 40, 10, 9, 5, 4, 1];
22  const symbols = ['M','CM','D','CD','C','XC','L','XL','X','IX','V','IV','I'];
23  let result = '';
24  for (let i = 0; i < values.length; i++) {
25    while (n >= values[i]) {
26      result += symbols[i];
27      n -= values[i];
28    }
29  }
30  return result;
31}
32// All three tests pass ✅
33
34// TRIANGULATION PATTERN:
35// Test 1: simplest case (may allow hardcoded solution)
36// Test 2: different specific case (forces first generalisation)
37// Test 3: edge case or boundary (forces complete generalisation)
38// After 3 triangulation points, the implementation is usually correct

1// Test list for a credit card validator:
2// (Written before any code, as a planning document)
3
4// BASIC STRUCTURE:
5// [ ] empty string → invalid
6// [ ] null/undefined → invalid
7// [ ] string with non-digits → invalid
8// [ ] 15-digit number → valid (Amex)
9// [ ] 16-digit number → valid (Visa/Mastercard)
10// [ ] 17-digit number → invalid
11
12// LUHN CHECK:
13// [ ] known valid Visa test card (4242424242424242) → valid
14// [ ] same number with last digit changed → invalid
15// [ ] known valid Amex test card → valid
16
17// CARD TYPE DETECTION:
18// [ ] starts with 4 → Visa
19// [ ] starts with 51-55 → Mastercard
20// [ ] starts with 34 or 37 → Amex
21// [ ] starts with other → Unknown
22
23// Start with the FIRST item and work down:
24
25test('returns invalid for empty string', () => {
26  expect(validateCard('').valid).toBe(false);
27});
28// Green: return { valid: false }
29
30test('returns invalid for non-digit characters', () => {
31  expect(validateCard('4111-1111-1111-1111').valid).toBe(false);
32});
33// Green: check for non-digits
34
35// Continue down the list...
36// Mark items as done as you complete them
37// Add new items to the list as you discover edge cases

1// WRONG order — jumps to complex before establishing simple:
2describe('parseDateRange', () => {
3  it('parses a complex range with timezones', () => {
4    // Requires: date parsing, timezone handling, range validation
5    expect(parseDateRange('2024-01-01T00:00:00Z/2024-12-31T23:59:59Z'))
6      .toEqual({ start: new Date('2024-01-01'), end: new Date('2024-12-31') });
7  });
8  // First test requires complete implementation → stuck in Green for 20 minutes
9});
10
11// CORRECT order — builds from simple to complex:
12describe('parseDateRange', () => {
13  it('throws for null input', () => {            // cycle 1: 30 seconds
14    expect(() => parseDateRange(null)).toThrow();
15  });
16
17  it('throws for invalid format', () => {         // cycle 2: 1 minute
18    expect(() => parseDateRange('not-a-date')).toThrow('Invalid date range');
19  });
20
21  it('parses a simple date-only range', () => {   // cycle 3: 2 minutes
22    const result = parseDateRange('2024-01-01/2024-12-31');
23    expect(result.start).toEqual(new Date('2024-01-01'));
24    expect(result.end).toEqual(new Date('2024-12-31'));
25  });
26
27  it('throws when end is before start', () => {   // cycle 4: 1 minute
28    expect(() => parseDateRange('2024-12-31/2024-01-01'))
29      .toThrow('End date must be after start date');
30  });
31
32  it('parses ISO 8601 datetime range with timezone', () => { // cycle 5: 3 minutes
33    const result = parseDateRange('2024-01-01T00:00:00Z/2024-12-31T23:59:59Z');
34    expect(result.start).toEqual(new Date('2024-01-01T00:00:00Z'));
35  });
36});
37// Each test adds one concept; the implementation grows incrementally

1// TOO LARGE — fails for too many reasons at once:
2test('creates a user, hashes password, saves to DB, sends email', async () => {
3  const result = await registerUser({
4    name: 'Alice',
5    email: '[email protected]',
6    password: 'SecurePass1!',
7  });
8  expect(result.id).toBeDefined();
9  expect(result.passwordHash).not.toBe('SecurePass1!');
10  expect(result.emailVerified).toBe(false);
11  const dbUser = await db.findByEmail('[email protected]');
12  expect(dbUser).toBeDefined();
13  const emails = await emailSpy.getCalls();
14  expect(emails).toHaveLength(1);
15  expect(emails[0].to).toBe('[email protected]');
16});
17// When this fails, you do not know which of the 6 assertions is the problem
18
19// SPLIT into 4 focused tests:
20test('returns a user with a generated id', async () => {
21  const result = await registerUser({ name: 'Alice', email: '[email protected]', password: 'Pass1!' });
22  expect(result.id).toBeDefined();
23});
24
25test('hashes the password — never stores plaintext', async () => {
26  const result = await registerUser({ name: 'Alice', email: '[email protected]', password: 'Pass1!' });
27  expect(result.passwordHash).not.toBe('Pass1!');
28  expect(result.passwordHash.startsWith('$2b$')).toBe(true); // bcrypt prefix
29});
30
31test('marks email as unverified initially', async () => {
32  const result = await registerUser({ name: 'Alice', email: '[email protected]', password: 'Pass1!' });
33  expect(result.emailVerified).toBe(false);
34});
35
36test('sends a welcome email to the registered address', async () => {
37  const emailSpy = jest.fn();
38  await registerUser({ name: 'Alice', email: '[email protected]', password: 'Pass1!' }, { sendEmail: emailSpy });
39  expect(emailSpy).toHaveBeenCalledWith(expect.objectContaining({ to: '[email protected]' }));
40});
41// Each test has one reason to fail — pinpoints exactly what broke