What is TDD? Why Do We Need It

With a passing test as your safety net, improve the code. Remove duplication, rename variables, extract functions — whatever makes the code cleaner. Run the tests after every change to make sure nothing breaks.

The key insight is that refactoring with tests is safe. Without tests, refactoring is gambling.

Then you repeat the cycle. Write the next failing test, make it pass, refactor. Over and over, building your application one small, tested piece at a time.

Why TDD?

Early in my career, I knew tests were important, but I always wrote them after the fact — if I wrote them at all. The result? Tests that were hard to write, tested the wrong things, and gave me false confidence.

When I started practicing TDD, three things changed:

It catches bugs early. When you write the test first, you think about edge cases before you write the code. You're forced to ask: what should happen when the input is empty? What if the user passes a number instead of a string? These questions come up naturally when you write the test, and you handle them before they become bugs in production.

It forces better design. Code that's easy to test is usually well-designed code. If you can't write a simple test for a function, it's often because the function is doing too much. TDD pushes you toward small, focused functions with clear inputs and outputs.

It gives you confidence to refactor. Without tests, changing existing code is scary. With a solid test suite, you can refactor aggressively and know immediately if you broke something. This is the real superpower of TDD — it makes your codebase maintainable over time.

Honest Trade-Offs

TDD isn't magic, and I want to be upfront about its costs:

• It's slower at first. Writing a test before every piece of code feels tedious when you're learning. You'll wonder if it's worth it. It is — but the payoff comes later, when you're debugging less and refactoring with confidence.
• There's a learning curve. Knowing what to test and how to structure tests takes practice. You'll write bad tests at first. That's normal.
• It's not always practical. Prototyping, UI exploration, one-off scripts — sometimes you need to experiment before you know what the test should be. TDD works best when you can clearly define the expected behavior upfront.

The goal of this course is to get you past the learning curve by building something real, step by step.

Your First TDD Example

Let's see the Red-Green-Refactor cycle in action with a simple example. We'll write a hello function that takes a name and returns a greeting.

Start by checking out the start branch:

You'll find two files:

Step 1: Write the Test (Red)

Open hello.test.js. This is our test file:

A few things to notice:

• We're using node:test and node:assert — these are built into Node.js. No need to install anything. No Jest, no Mocha, no dependencies at all.
• describe groups related tests together.
• it defines a single test case — a specific behavior we expect.
• assert.strictEqual checks that the result exactly matches what we expect.

The test says: "When I call hello('Tung'), it should return 'Hello, Tung'."

Now look at hello.js — the implementation file:

The function exists, but it doesn't do anything. It returns undefined.

Run the test:

You'll see output like this:

Red. The test fails because hello('Tung') returns undefined instead of 'Hello, Tung'. This is exactly what we want. We've defined the behavior, and now we know it doesn't work yet.

Step 2: Make It Pass (Green)

Now let's write the simplest code that makes the test pass. Update hello.js:

Run the test again:

Green. The test passes. We wrote the minimum code needed — a template literal that combines "Hello, " with the name.

You can verify this by checking out the finish branch:

The code there matches exactly what we just wrote.

Step 3: Refactor

In this example, there's nothing to refactor — the code is already as simple as it can be. But in real-world scenarios, this is where you'd clean up. Maybe you extracted a helper function, maybe you renamed a variable, maybe you noticed some duplication. The point is: with a passing test, you can make changes confidently.

That's the complete Red-Green-Refactor cycle. Write a failing test, make it pass, clean up. We'll follow this exact pattern throughout the entire course.

In the next chapter, we'll set up the actual project — scaffolding a Fastify application and writing our first real failing test.