What is TDD? Why Do We Need It

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

Refactoring with tests is safe. Without tests, refactoring is gambling.

Then you repeat the cycle. Write the next failing test, make it pass, and refactor. You build 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. The result was usually 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. Writing the test first makes you think about edge cases before you write the code. You are forced to ask: what should happen when the input is empty? What if the user passes a number instead of a string? You handle these questions naturally before they become bugs in production.

It forces better design. Code that is easy to test is usually well-designed code. If you cannot write a simple test for a function, it is 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. Changing existing code without tests is scary. With a solid test suite, you can refactor aggressively and know immediately if you broke something. This makes your codebase maintainable over time.

Honest Trade-Offs

TDD is not magic. It has real costs:

• It is slower at first. Writing a test before every piece of code feels tedious when you are learning. The payoff comes later when you spend far less time debugging and can refactor with confidence.
• There is a learning curve. Knowing what to test and how to structure tests takes practice. You will write bad tests at first, and that is normal.
• It is not always practical. For prototyping, UI exploration, or one-off scripts, you sometimes 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

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

Start by checking out the start branch:

You will find two files:

Step 1: Write the Test (Red)

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

A few things to notice:

• We are using node:test and node:assert. These are built into Node.js. There is no need to install Jest, Mocha, or any other dependencies.
• describe groups related tests together.
• it defines a single test case for 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 does not do anything. It returns undefined.

Run the test:

You will see output like this:

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

Step 2: Make It Pass (Green)

Now 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, the code is already as simple as it can be. In real-world scenarios, this is where you clean up. You might extract a helper function, rename a variable, or remove duplication. With a passing test, you can make these changes confidently.

Write a failing test, make it pass, clean up. We will follow this exact pattern throughout the entire course.

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