TDD Isn’t About Bugs — It’s Your Permission to Refactor#

The Moment It Clicked#

Three years ago, I had a crisis of confidence with test-driven development.

I’d built a user registration system with 80% test coverage, all green, CI passing. Then I decided to refactor the email validation logic: just move it to a separate module. A tiny change.

Thirty minutes later, everything was broken.

My tests tested how the code worked, not what it did. The moment the structure changed, they failed. I spent more time fixing tests than doing the refactoring itself.

I’ll show you what I was doing wrong. It might look familiar.

The Trap: Testing Structure#

Here’s the TypeScript code I had, a User class with inline validation:

1
class User {
2
  email: string;
3
  age: number;
4

5
  constructor(email: string, age: number) {
6
    if (!email.includes("@")) {
7
      throw new Error("Invalid email");
8
    }
9
    if (age < 18) {
10
      throw new Error("Must be at least 18 years old");
11
    }
12
    this.email = email;
13
    this.age = age;
14
  }
15
}

And the test:

1
describe("User", () => {
2
  it("should create a user", () => {
3
    const user = new User("[email protected]", 25);
4
    expect(user.email).toBe("[email protected]");
5
    expect(user.age).toBe(25);
6
  });
7
});

What am I testing? Structure. I’m reaching into the object and checking its properties directly.

Now watch what happens when I hide the internals:

1
class User {
2
  private email: string;
3
  private age: number;
4

5
  constructor(email: string, age: number) {
6
    if (!email.includes("@")) {
7
      throw new Error("Invalid email");
8
    }
9
    if (age < 18) {
10
      throw new Error("Must be at least 18 years old");
11
    }
12
    this.email = email;
13
    this.age = age;
14
  }
15

16
  get email(): string {
17
    return this.email;
18
  }
19

20
  get age(): number {
21
    return this.age;
22
  }
23
}

The test breaks. The behavior hasn’t changed (the same user is created with the same rules), but I changed the structure.

I’m now rewriting tests for a refactoring that shouldn’t require any test changes.

The Fix: Test Behavior#

The solution: test what the code does, not how it’s organized.

But first, I need to fix another problem. Throwing exceptions makes testing awkward: you need expect(() => fn()).toThrow(), which hides the error behind a callback. The fix is treating errors as first-class values instead of hidden control flow.

Here’s the pattern that made this click, the Result type:

1
type Result<T, E> =
2
  | { readonly ok: true; readonly value: T }
3
  | { readonly ok: false; readonly error: E };
4

5
function ok<T>(value: T): Result<T, never> {
6
  return { ok: true, value };
7
}
8

9
function err<E>(error: E): Result<never, E> {
10
  return { ok: false, error };
11
}

Instead of throwing, functions return a Result that’s either a success or a failure. Both paths are explicit. No try/catch. Errors are data you can inspect, test, and chain. (In production code, you’d use a library like neverthrow which adds map, flatMap, and match for composing results.)

With Result in place, I can rewrite the User class with a static factory method:

1
class UserCreationError {
2
  constructor(
3
    public readonly message: string,
4
    public readonly field: string
5
  ) {}
6
}
7

8
class User {
9
  private constructor(
10
    private readonly _email: string,
11
    private readonly _age: number
12
  ) {}
13

14
  static create(email: string, age: number): Result<User, UserCreationError> {
15
    if (!email.includes("@")) {
16
      return err(new UserCreationError("Invalid email format", "email"));
17
    }
18
    if (age < 18) {
19
      return err(new UserCreationError("Must be at least 18 years old", "age"));
20
    }
21
    return ok(new User(email, age));
22
  }
23

24
  get email(): string {
25
    return this._email;
26
  }
27

28
  get age(): number {
29
    return this._age;
30
  }
31
}

Now the tests verify behavior, the observable contract:

1
describe("User Registration", () => {
2
  it("should create a user with valid email and age", () => {
3
    const result = User.create("[email protected]", 25);
4

5
    expect(result.ok).toBe(true);
6
    if (result.ok) {
7
      expect(result.value.email).toBe("[email protected]");
8
      expect(result.value.age).toBe(25);
9
    }
10
  });
11

12
  it("should reject invalid emails", () => {
13
    const result = User.create("not-an-email", 25);
14

15
    expect(result.ok).toBe(false);
16
    if (!result.ok) {
17
      expect(result.error.field).toBe("email");
18
      expect(result.error.message).toMatch(/email/i);
19
    }
20
  });
21

22
  it("should reject users under 18", () => {
23
    const result = User.create("[email protected]", 17);
24

25
    expect(result.ok).toBe(false);
26
    if (!result.ok) {
27
      expect(result.error.message).toMatch(/18/);
28
    }
29
  });
30
});

When I refactor the internals now (make _email private, change the data structure, extract a class), these tests keep passing. They test the contract: valid inputs succeed, invalid inputs fail with the right error. The internal structure is irrelevant.

This is the red-green-refactor cycle that defines test-driven development: write a failing test (red), make it pass with the simplest code (green), then improve the design while keeping tests green (refactor). The tests give you permission to refactor aggressively because they catch real problems, not structural changes.

Going Deeper: Value Objects#

Once I started testing behavior, I noticed something. My validation logic was scattered. The same email check appeared in registerUser, changeEmail, and resetPassword. Three places, same rule, same potential for bugs.

The fix is a Value Object: a small, self-validating type that represents a single concept. If you have an Email instance, it’s valid by construction:

1
class InvalidEmailError {
2
  readonly message = "Invalid email format";
3
}
4

5
class Email {
6
  private constructor(private readonly _value: string) {}
7

8
  static create(raw: string): Result<Email, InvalidEmailError> {
9
    const value = raw.trim().toLowerCase();
10
    if (!value.includes("@")) {
11
      return err(new InvalidEmailError());
12
    }
13
    return ok(new Email(value));
14
  }
15

16
  get value(): string {
17
    return this._value;
18
  }
19

20
  equals(other: Email): boolean {
21
    return this._value === other._value;
22
  }
23
}

Notice the normalization (trim().toLowerCase()) lives inside the Value Object. Every Email instance is guaranteed lowercase and trimmed. The validation rule exists in one place. If the rule changes, you change one class.

Similarly for Age:

1
class InvalidAgeError {
2
  readonly message = "Must be at least 18 years old";
3
}
4

5
class Age {
6
  private constructor(private readonly _value: number) {}
7

8
  static create(value: number): Result<Age, InvalidAgeError> {
9
    if (!Number.isInteger(value) || value < 18) {
10
      return err(new InvalidAgeError());
11
    }
12
    return ok(new Age(value));
13
  }
14

15
  get value(): number {
16
    return this._value;
17
  }
18
}

The User class now composes these Value Objects instead of accepting raw primitives:

1
class User {
2
  private constructor(
3
    private readonly _email: Email,
4
    private readonly _age: Age
5
  ) {}
6

7
  static create(email: string, age: number): Result<User, UserCreationError> {
8
    const emailResult = Email.create(email);
9
    if (!emailResult.ok)
10
      return err(new UserCreationError(emailResult.error.message, "email"));
11

12
    const ageResult = Age.create(age);
13
    if (!ageResult.ok)
14
      return err(new UserCreationError(ageResult.error.message, "age"));
15

16
    return ok(new User(emailResult.value, ageResult.value));
17
  }
18

19
  get email(): string {
20
    return this._email.value;
21
  }
22

23
  get age(): number {
24
    return this._age.value;
25
  }
26
}

The same tests from before still pass. They test User.create() returning success or failure, which hasn’t changed. The internal composition with Value Objects is invisible to the tests.

The Payment System#

Last year, I refactored a production payment processing module: about 2,400 lines of conditional logic scattered across processPayment, validatePayment, and handleRefund. Validation rules were duplicated in all three functions.

The old tests looked like this:

1
it("processes payment", () => {
2
  const processor = new PaymentProcessor(mockGateway, mockDB);
3
  processor.validateAmount(100);
4
  processor.validateCurrency("USD");
5
  const result = processor.process({ amount: 100, currency: "USD" });
6
  expect(result.status).toBe("success");
7
  expect(mockGateway.charge).toHaveBeenCalledTimes(1);
8
});

Those tests called internal methods directly. When I extracted validation into a Payment Value Object, every test broke because validateAmount and validateCurrency no longer existed as separate methods.

I rewrote the tests to focus on the contract:

1
it("accepts valid payments", () => {
2
  const result = Payment.create({ amount: 100, currency: "USD" });
3
  expect(result.ok).toBe(true);
4
});
5

6
it("rejects negative amounts", () => {
7
  const result = Payment.create({ amount: -50, currency: "USD" });
8
  expect(result.ok).toBe(false);
9
});

Then I refactored aggressively. Extracted Currency as its own Value Object. Moved validation into the Payment factory. Deleted 800 lines of duplicated logic. Tests never broke once, because they tested what happened, not how.

The whole refactoring took a day. With the old tests, it would have taken a week: three days of refactoring, two days of fixing tests.

The same idea shows up in concurrency code too. When you refactor a pipeline or a worker pool, the contract stays the same while the internals change. The tests that survive are the ones that verify behavior, not goroutine counts.

The “TDD Is Slow” Myth#

I used to think test-driven development slowed me down. Studies tell a more nuanced story: TDD has a modest upfront cost of 10–30% more development time, but reduces defects by 40–90% (Nagappan et al., Microsoft/IBM, 2008). George & Williams (2003) found TDD pairs took 16% more time but passed 18% more black-box tests.

The upfront cost is real. The payoff is also real. And it compounds: every safe refactoring makes the next one easier.

When I couldn’t refactor safely, I coded defensively. I avoided changes. I left bad code in place because changing it was risky. Refactoring without tests is what’s actually slow. It compounds with every month.

When TDD Doesn’t Help#

Test-driven development isn’t always the right tool. Spikes and prototypes (code you’ll throw away) don’t need tests. Exploratory work where you don’t know the shape of the solution yet. UI code where the behavior is visual, not logical. One-off scripts. Code with genuinely unstable requirements that change every sprint.

TDD pays off when you’re building something you’ll maintain and refactor over time. If the code won’t survive the week, write the minimum.

Monday Morning#

Take one function you wrote recently. Rewrite its tests to verify behavior (what it does) instead of implementation (how it’s organized).

Watch what happens to your code.

Three years ago, I was afraid to refactor. Now I do it aggressively, because my tests give me permission. Test-driven development gave me a permission slip I didn’t know I needed.

Next time, I’ll show you how to build Value Objects that make invalid states impossible, and how testing them first makes the design emerge naturally.

If you found this useful, the next article in the series shows how to build Value Objects that make invalid states impossible. It comes out in a couple of weeks. You can subscribe via RSS or Atom to catch it when it lands.

— Corentin