Master Test-Driven Development with a Hands-On FizzBuzz Example

Intro

Many developers experience late‑night bugs, broken interfaces, and stressful code reviews. The author claims that adopting Test‑Driven Development (TDD) can shorten workdays, reduce bugs, and improve team harmony.

Why TDD?

Without automated tests, code can become a ticking bomb. TDD, a practice from Extreme Programming (XP), helps avoid such situations.

Feel the Problem – A Simple FizzBuzz Kata

The article uses the classic FizzBuzz problem (print numbers 1‑100, replace multiples of 3 with "Fizz", multiples of 5 with "Buzz", and multiples of both with "FizzBuzz") as a concrete example.

Problem template: git clone https://github.com/bruceeewong/tdd-kata.git -b kick-start

Requirements

Clean code without duplication

Unit tests with 100% coverage

Complete within 5 minutes

Analysis

The author breaks the requirement down into testable units: input → process → output. The first test asserts that fizzbuzz(1) returns the string "1".

const fizzbuzz = require("./fizzbuzz");

describe("fizzbuzz", () => {
  test("returns normal number", () => {
    expect(fizzbuzz(1)).toEqual("1");
  });
});

Running jest fails because the function is not defined.

function fizzbuzz(num) {
  return '1';
}
module.exports = fizzbuzz;

After the test passes (green), the next failing test checks the handling of multiples of 3.

test("returns Fizz for multiples of 3", () => {
  expect(fizzbuzz(3)).toEqual("Fizz");
});

Implement the logic step by step, eliminating duplication by extracting a helper canDivideBy function.

function fizzbuzz(num) {
  function canDivideBy(num, divideNum) {
    return num % divideNum === 0;
  }
  if (canDivideBy(num, 15)) return "FizzBuzz";
  if (canDivideBy(num, 3)) return "Fizz";
  if (canDivideBy(num, 5)) return "Buzz";
  return num.toString();
}
module.exports = fizzbuzz;

All tests now pass, achieving 100% coverage.

Diving Deeper into TDD

TDD is defined as a mindset that bridges the gap between decision and feedback during programming. It can be described as a way to manage fear in coding and a development style driven by automated tests.

Clean code that works.

TDD Development Cycle

What is a test? – an action that verifies expected behavior.

What to test? – program‑level unit tests focusing on logic and data.

When to test? – before writing code (red) and before refactoring (green).

Red Bar Patterns

Write a failing test first (red), then make it pass.

Green Bar Patterns

Techniques to get the test to pass quickly:

Fake It ('Til You Make It) – return a constant to satisfy the test.

Triangulate – write tests from different angles, let the failing implementation guide refactoring.

Obvious Implementation – write the simplest code that satisfies the test.

Summary of TDD Benefits

Forces clear thinking about requirements.

Provides a concrete definition of “done”.

Tests serve as living documentation.

Seeing green bars gives confidence and satisfaction.

Challenges of TDD

TDD shines for unit tests but is less suitable for GUI testing, database‑dependent tests (where mocks are needed), third‑party code, or compiler testing.

Final Thoughts

As a web front‑end developer, the author uses TDD for business logic, noting the following personal gains:

Predictable development experience – when all tests pass, the code is reliable.

A safety net for refactoring – tests allow you to improve code without fear.

Maintain youthful code – clear I/O and idempotent behavior.

Team confidence – colleagues can understand usage through tests.

To explore TDD further, read Kent Beck’s “Test‑Driven Development By Example”.