testing

Test-Driven Development

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

The Iron Law

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

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

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

When to Use

Always:

• New features
• Bug fixes
• Refactoring
• Behavior changes

Exceptions (ask first):

• Throwaway prototypes
• Generated code
• Configuration files

Thinking "skip TDD just this once"? Stop. That's rationalization.

Red-Green-Refactor

RED - Write Failing Test

Write one minimal test showing what should happen.

// Good: Clear name, tests real behavior, one thing
test('rejects empty email', async () => {
  const result = await submitForm({ email: '' });
  expect(result.error).toBe('Email required');
});

// Bad: Vague name, tests mock not code
test('form works', async () => {
  const mock = jest.fn().mockResolvedValue('success');
  await submitForm(mock);
  expect(mock).toHaveBeenCalled();
});

Requirements:

• One behavior per test
• Clear descriptive name
• Real code (no mocks unless unavoidable)

Verify RED - Watch It Fail

MANDATORY. Never skip.

npm test path/to/test.test.ts

Confirm:

• Test fails (not errors)
• Failure message is expected
• Fails because feature missing (not typos)

Test passes? You're testing existing behavior. Fix the test.

GREEN - Minimal Code

Write the simplest code to pass the test.

// Good: Just enough to pass
function validateEmail(email: string): string | null {
  if (!email?.trim()) return 'Email required';
  return null;
}

// Bad: Over-engineered
function validateEmail(
  email: string,
  options?: {
    allowEmpty?: boolean;
    customRegex?: RegExp;
    onValidate?: (email: string) => void;
  }
): ValidationResult {
  // YAGNI - don't add features not tested
}

Don't add features, refactor other code, or "improve" beyond the test.