The Moment It Clicked#

Three years ago, I had a crisis of confidence with testing.

I’d built a user registration system that was covered—I thought. 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.

Not because the refactoring was bad. Because my tests were brittle. They tested how the code worked, not what it did. The moment the structure changed, they failed.

I had to rewrite half the test suite just to make the refactoring work.

That’s when I realized: I didn’t understand TDD at all.

I thought TDD was about catching bugs. It’s not.

TDD is about permission.

Permission to refactor your code without fear. Permission to improve the design while keeping behavior the same. Permission to say, “I’m going to change everything about how this works, and I’m confident nothing will break.”

That’s the real power.

The Problem: Testing Implementation vs. Behavior#

Let me show you what I was doing wrong.

Here’s the old code (the kind that breaks when you refactor):

1
// ❌ This test is brittle
2

3
class User {
4
  email: string;
5
  age: number;
6

7
  constructor(email: string, age: number) {
8
    if (!email.includes("@")) {
9
      throw new Error("Invalid email");
10
    }
11
    if (age < 18) {
12
      throw new Error("Too young");
13
    }
14
    this.email = email;
15
    this.age = age;
16
  }
17
}
18

19
// The brittle test
20
describe("User", () => {
21
  it("should create a user", () => {
22
    const user = new User("alice@example.com", 25);
23
    expect(user.email).toBe("alice@example.com"); // ❌ Tests structure
24
    expect(user.age).toBe(25); // ❌ Tests structure
25
  });
26
});

What am I testing here? Structure. Not behavior.

Now, what happens when I refactor to hide the email property?

1
// Refactored (slightly better design)
2

3
class User {
4
  private email: string; // ❌ Now private
5
  private age: number;   // ❌ Now private
6

7
  constructor(email: string, age: number) {
8
    if (!email.includes("@")) {
9
      throw new Error("Invalid email");
10
    }
11
    if (age < 18) {
12
      throw new Error("Too young");
13
    }
14
    this.email = email;
15
    this.age = age;
16
  }
17

18
  getEmail(): string {
19
    return this.email;
20
  }
21

22
  getAge(): number {
23
    return this.age;
24
  }
25
}

My test breaks. Not because the behavior changed. Because I changed the structure.

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

That’s the trap.

The Shift: Test Behavior, Not Implementation#

The fix is simple: test what the code does, not how it’s organized.

Here’s what I learned:

1
// ✅ This test is robust
2

3
// A test that verifies BEHAVIOR, not structure
4
describe("User Registration", () => {
5
  it("should successfully create a user with valid email and age", () => {
6
    // Behavior: Can I create a user with valid inputs?
7
    const result = User.create("alice@example.com", 25);
8

9
    expect(result.ok).toBe(true);
10
    expect(result.value.getEmail().getValue()).toBe("alice@example.com");
11
  });
12

13
  it("should reject users without @ in email", () => {
14
    // Behavior: Invalid email is rejected
15
    const result = User.create("not-an-email", 25);
16

17
    expect(result.ok).toBe(false);
18
    expect(result.error.message).toMatch(/email/i);
19
  });
20

21
  it("should reject users under 18", () => {
22
    // Behavior: Age rule is enforced
23
    const result = User.create("alice@example.com", 17);
24

25
    expect(result.ok).toBe(false);
26
    expect(result.error.message).toMatch(/18/i);
27
  });
28
});

Now, when I refactor the internals, these tests don’t break. They test the contract, not the implementation.

This is TDD’s real power.

Enter: The Result<T, E> Pattern#

Here’s the pattern that made this click for me: Result types.

Instead of throwing exceptions (which are hidden control flow), treat errors as first-class values.

1
// The Result Type (the permission slip)
2

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

7
// Helper functions to create Results
8
function ok<T>(value: T): Result<T, never> {
9
  return { ok: true, value };
10
}
11

12
function err<E>(error: E): Result<never, E> {
13
  return { ok: false, error };
14
}

Now, instead of:

1
// ❌ Old way: exceptions (hidden, hard to test)
2

3
function validateEmail(email: string) {
4
  if (!email.includes("@")) {
5
    throw new Error("Invalid email");
6
  }
7
  return email;
8
}
9

10
// Testing this is awkward
11
expect(() => validateEmail("bad")).toThrow();

You do:

1
// ✅ New way: explicit Results
2

3
class InvalidEmailError {
4
  message = "Invalid email format";
5
}
6

7
function validateEmail(email: string): Result<string, InvalidEmailError> {
8
  const normalized = email.trim().toLowerCase();
9

10
  if (!normalized.includes("@")) {
11
    return err(new InvalidEmailError());
12
  }
13

14
  return ok(normalized);
15
}
16

17
// Testing this is crystal clear
18
const result = validateEmail("bad");
19
if (!result.ok) {
20
  console.log(result.error.message); // ✅ Explicit
21
}

Why does this matter for TDD?

Because now your tests are explicit about both paths (success and failure). You’re not relying on exceptions to convey intent. Errors are data.

The Real Impact: My Refactoring Story#

Fast forward to last year. I was refactoring a production payment system.

Thousands of lines. Complex state. High stakes.

With my old approach (exceptions + brittle tests), I would have spent a week on this.

With Result<T, E> + behavior-based tests, I spent a day.

Here’s why:

Old approach:

1. Write refactoring
2. Tests break (because they test structure)
3. Rewrite tests while refactoring
4. Uncertainty: “Did I break something, or just the tests?”
5. Conservative refactoring (minimalist changes to keep tests green)
6. Weak design improvements

New approach:

1. Write refactoring
2. Tests still pass (because they test behavior)
3. Confidence: “Tests pass = behavior is preserved”
4. Bold refactoring (aggressive design improvements)
5. Strong design improvements, high confidence

The tests become a permission slip. You can refactor aggressively because you trust the tests to catch real problems, not structural changes.

That payment system? I cleaned up 40% of the code while improving performance by 30%. The tests guided me every step.

With the old tests, I would have tiptoed through it.

Why This Matters: The Three Levels#

Let me be clear about what’s happening here. There are three levels to testing:

1
// ❌ Level 1: Testing implementation
2
it("should set email to alice@example.com", () => {
3
  const user = new User("alice@example.com", 25);
4
  expect(user.email).toBe("alice@example.com");
5
});

1
// ✅ Level 2: Testing observable behavior
2
it("should accept valid emails", () => {
3
  const result = User.create("alice@example.com", 25);
4
  expect(result.ok).toBe(true);
5
});
6

7
it("should reject invalid emails", () => {
8
  const result = User.create("no-at", 25);
9
  expect(result.ok).toBe(false);
10
});

1
// ✅ Level 3: Tests guide design
2
// Tests are written FIRST, guiding the implementation
3

4
describe("Email Value Object", () => {
5
  it("should create valid email", () => {
6
    const result = Email.create("alice@example.com");
7
    expect(result.ok).toBe(true);
8
  });
9

10
  it("should reject invalid email", () => {
11
    const result = Email.create("no-at");
12
    expect(result.ok).toBe(false);
13
  });
14
});
15

16
// Now, to make these tests pass, you *design* an Email class
17
// that validates itself. The design emerges from the tests.

The Myth: “TDD Is Slow”#

I used to think this.

“TDD slows me down. I just want to code.”

Then I realized: TDD isn’t slow. Refactoring without tests is slow.

When I couldn’t refactor safely (old approach), I coded defensively. I avoided changes. I left bad code in place because changing it was risky.

That’s actually slow. It compounds with every month.

With TDD + Result<T, E>:

• I refactor constantly
• Design improves over time
• Code becomes easier to change
• New features are faster

The upfront “time” of writing tests disappears when you count the refactoring time you save.

The Second Shift: Encoding Rules Into Types#

Once I understood this, I realized the next level: encoding your domain rules into types themselves.

Instead of:

1
// ❌ Rules scattered everywhere
2

3
function registerUser(email: string, age: number) {
4
  // Validation here
5
  if (!email.includes("@")) {
6
    return err(new InvalidEmailError());
7
  }
8

9
  // And here
10
  if (age < 18) {
11
    return err(new InvalidAgeError());
12
  }
13

14
  // And again here
15
  const user = new User(email, age);
16
  // ...
17
}
18

19
function changeEmail(userId: string, newEmail: string) {
20
  // Validation repeated
21
  if (!newEmail.includes("@")) {
22
    return err(new InvalidEmailError());
23
  }
24

25
  // ...
26
}

You create Value Objects that validate themselves:

1
// ✅ Rules encoded in types
2

3
class Email {
4
  private constructor(private readonly value: string) {}
5

6
  static create(value: string): Result<Email, InvalidEmailError> {
7
    if (!value.includes("@")) {
8
      return err(new InvalidEmailError());
9
    }
10
    return ok(new Email(value));
11
  }
12

13
  getValue(): string {
14
    return this.value;
15
  }
16
}
17

18
class Age {
19
  private constructor(private readonly value: number) {}
20

21
  static create(value: number): Result<Age, InvalidAgeError> {
22
    if (value < 18) {
23
      return err(new InvalidAgeError());
24
    }
25
    return ok(new Age(value));
26
  }
27

28
  getValue(): number {
29
    return this.value;
30
  }
31
}
32

33
// Now these functions are trivial
34
function registerUser(emailStr: string, ageNum: number) {
35
  const emailResult = Email.create(emailStr);
36
  if (!emailResult.ok) return err(emailResult.error);
37

38
  const ageResult = Age.create(ageNum);
39
  if (!ageResult.ok) return err(ageResult.error);
40

41
  return ok(new User(emailResult.value, ageResult.value));
42
}

The rules live in one place: the Email and Age classes.

Every time you use Email, you get validation for free. No repeated validation logic. No scattered rules.

This is what happens when you design from tests.

How This Changed My Code#

Let me be concrete. Here’s what changed:

Before (2021):

• 500-line “User” class (doing too much)
• Validation scattered across 4 different modules
• Tests were brittle (implementation-focused)
• Refactoring took weeks
• Bugs appeared after refactoring

After (2024):

• Email, Age classes (focused, ~50 lines each)
• Validation in one place (the Value Object)
• Tests are robust (behavior-focused)
• Refactoring takes days
• No regressions

The difference? TDD + Result<T, E> + thinking about design as “what tests do I need?”

The Permission Slip Moment#

Here’s the metaphor that stuck with me:

Tests are a permission slip.

When you have good tests, you have permission to:

• ✅ Refactor aggressively
• ✅ Improve design
• ✅ Change internals
• ✅ Delete code
• ✅ Reorganize modules
• ✅ Take risks

Without good tests, you don’t have permission. You code conservatively. You leave bad code in place because changing it is scary.

That’s not sustainable.

TDD gives you permission.

But only if you test behavior, not implementation. Only if you treat errors as values, not exceptions. Only if you encode your rules into types.

The Myth-Bust#

“But TDD is slow” → No, refactoring without tests is slow. TDD saves time long-term.

“But tests are boring” → No, they’re your design conversation. They tell you what your code should do before you write it.

“But I’ll add tests later” → You won’t. And if you do, they’ll be brittle because you’ll test implementation.

“But I don’t have time” → You don’t have time not to. The time you “save” now costs you 10x later in technical debt.

“But this is overkill for simple code” → No code stays simple. Today’s simple code becomes tomorrow’s complex system. Better to start right.

What This Means For You#

If you’re reading this and thinking, “Yeah, I’ve felt this pain,” here’s what I want you to do:

This week:

1. Take one function you wrote recently
2. Rewrite its tests to verify behavior instead of implementation
3. Notice how it changes your function design

That’s it. One function.

When you do this, you’ll feel the shift. You’ll see how tests guide design.

That’s TDD.

Next week, we’re going deeper. I’ll show you:

• How to structure code so it’s testable (Value Objects + Entities)
• How to refactor safely (Aggregates + Repositories)
• How to build systems that don’t break (Domain-Driven Design)

Each article builds on this one: test behavior, not implementation.

The Real Reason I’m Writing This#

I’m building a course on TDD + DDD for backend developers.

Not because testing is trendy. Because I’ve seen teams transform when they understand this.

Code that was a mess becomes elegant. Developers who were afraid to refactor become confident. Systems that were brittle become robust.

The shift is always the same: test behavior, give yourself permission, improve design.

If that resonates, I have a free cheatsheet that breaks down the key patterns (Result<T, E>, Value Objects, Aggregates). Grab it below.

And if you want the full system—how to build backends that don’t break—the course is coming in a few weeks.

For now, start with one function. Rewrite its tests. Feel the shift.

That’s the permission slip.

Summary: The Permission Slip#

TDD isn’t about catching bugs. It’s about permission.

Permission to refactor without fear. Permission to improve design. Permission to change internals while keeping behavior the same.

To get this permission:

1. Test behavior, not implementation — What does your code do, not how?
2. Treat errors as values — Use Result<T, E> instead of exceptions
3. Encode rules into types — Value Objects that validate themselves
4. Refactor boldly — Tests will catch real problems, not structural changes

The pattern that makes this concrete is the Result<T, E> type. It makes errors explicit, tests easier, and refactoring safer.

I spent three years learning this. You can understand it in one article.

Then the real work begins: designing systems that don’t break.

That’s next week.

For now, grab the cheatsheet. It has the patterns. And start with one function.

What’s Next?#

Next article: “Value Objects & Entities — Building Blocks That Can’t Break”

We’ll build on this foundation and show how to structure your code so that invalid states become impossible. Not just hard to create, but literally impossible. Your types will reject bad data before it exists.

Subscribe below for the full series. Each article builds on the last.

The Free Gift: TDD Cheatsheet#

[LEAD MAGNET FORM HERE - ConvertKit]

Get the TDD Cheatsheet: 8-page PDF with the patterns, the Result<T, E> type, testing templates, and a checklist to audit your own code.

Questions? Hit reply. I read everything.

— Corentin

P.S. If you’re thinking “this is too much,” it’s not. Start with one function. Rewrite its tests to test behavior. See what happens. That’s TDD. The rest is just scaling up what you’ve already learned.