Test-Driven Development (TDD) in JavaScript: Red-Green-Refactor Cycle

Master Test-Driven Development in JavaScript with the Red-Green-Refactor cycle. Learn TDD workflow, practical examples, benefits, and best practices for writing better code.

Introduction
What is Test-Driven Development?
The Red-Green-Refactor Cycle
Setting Up TDD Environment
TDD Workflow: Step-by-Step Guide
Writing Good Tests First
TDD Patterns and Techniques
TDD with Different Code Types
Benefits of Test-Driven Development
Common Challenges and Solutions
TDD Best Practices
When Not to Use TDD
Conclusion

Introduction

Test-Driven Development (TDD) is a software development methodology that has revolutionized how developers write code. Instead of writing code first and testing it later, TDD flips the traditional approach: you write tests first, watch them fail, then write the minimum code needed to make them pass. This simple inversion creates a powerful feedback loop that leads to better design, fewer bugs, and more maintainable code.

In JavaScript development, TDD has become increasingly important as applications grow in complexity. Whether you’re building React components, Node.js APIs, or vanilla JavaScript utilities, TDD provides a structured approach to development that ensures your code works correctly from the start and continues to work as you refactor and extend it.

This comprehensive guide will teach you everything you need to know about Test-Driven Development in JavaScript. You’ll learn the fundamental Red-Green-Refactor cycle, see practical examples using popular testing frameworks like Jest and Vitest, understand when and how to apply TDD effectively, and discover the benefits and challenges of this approach. By the end, you’ll have the knowledge and confidence to start practicing TDD in your own projects.

What is Test-Driven Development?

Test-Driven Development is a software development process that follows a simple but powerful workflow:

Write a failing test (Red)
Write the minimum code to make it pass (Green)
Refactor the code while keeping tests green (Refactor)
Repeat

This cycle, known as Red-Green-Refactor, forms the foundation of TDD. The key insight is that by writing tests first, you’re forced to think about your code’s interface and behavior before implementation, leading to better design decisions.

Core Principles of TDD

TDD is built on several fundamental principles:

Test First: Tests are written before the implementation code. This ensures that every piece of functionality has a test from the beginning.

Small Steps: TDD encourages taking small, incremental steps. Write one test, make it pass, refactor, then move to the next test.

Fail First: Tests must fail initially (Red phase). This confirms that your test is actually testing something and that the failure is due to missing functionality, not a broken test.

Minimal Implementation: Write only the code necessary to make the test pass. Avoid over-engineering or adding features not covered by tests.

Refactor Safely: Once tests pass, you can refactor with confidence, knowing that tests will catch any regressions.

TDD vs Traditional Testing

Traditional development typically follows this flow:

Write Code → Write Tests → Fix Bugs → Refactor (risky)

TDD follows this flow:

Write Tests → Write Code → Refactor (safe) → Repeat

The key difference is that TDD uses tests to drive design and implementation, while traditional testing uses tests to verify existing code. This shift in perspective leads to different outcomes:

Better Design: Writing tests first forces you to think about how code will be used, leading to cleaner APIs
Higher Test Coverage: Since tests come first, coverage is naturally higher
Faster Feedback: You know immediately if your code works
Safer Refactoring: Comprehensive tests give you confidence to improve code structure

The Red-Green-Refactor Cycle

The Red-Green-Refactor cycle is the heartbeat of TDD. Understanding each phase is crucial to practicing TDD effectively.

🔴 Red Phase: Write a Failing Test

In the Red phase, you write a test that describes the behavior you want to implement. The test should fail because the functionality doesn’t exist yet.

Why Red? The test fails, and most test runners display failures in red. More importantly, seeing the test fail confirms:

Your test is actually running
The test is testing the right thing
The failure is due to missing functionality, not a broken test

// Example: Testing a simple calculator function
describe("Calculator", () => {
  test("should add two numbers", () => {
    expect(add(2, 3)).toBe(5);
  });
});

// This test will fail because `add` doesn't exist yet
// Error: ReferenceError: add is not defined

🟢 Green Phase: Make the Test Pass

In the Green phase, you write the minimum code necessary to make the test pass. Don’t worry about perfect code yet—just make it work.

Why Green? Passing tests are typically displayed in green. The goal here is speed and simplicity, not perfection.

// Minimal implementation to make the test pass
function add(a, b) {
  return a + b;
}

// Test now passes ✅

🔵 Refactor Phase: Improve the Code

In the Refactor phase, you improve the code structure, readability, and design while keeping all tests green. This is where you apply best practices, remove duplication, and optimize.

Why Refactor? The Green phase often produces code that works but isn’t elegant. Refactoring improves code quality while tests ensure you don’t break anything.

// Refactored version - still passes all tests
function add(...numbers) {
  return numbers.reduce((sum, num) => sum + num, 0);
}

// All tests still pass ✅

The Complete Cycle in Action

Let’s see a complete example of the Red-Green-Refactor cycle:

// 🔴 RED: Write failing test
describe("StringUtils", () => {
  test("should capitalize first letter", () => {
    expect(capitalize("hello")).toBe("Hello");
  });
});

// 🟢 GREEN: Minimal implementation
function capitalize(str) {
  return str[0].toUpperCase() + str.slice(1);
}

// 🔵 REFACTOR: Improve implementation
function capitalize(str) {
  if (!str) return "";
  return str.charAt(0).toUpperCase() + str.slice(1).toLowerCase();
}

// Add more tests and repeat the cycle
test("should handle empty strings", () => {
  expect(capitalize("")).toBe("");
});

test("should handle already capitalized strings", () => {
  expect(capitalize("Hello")).toBe("Hello");
});

Setting Up TDD Environment

Before you can practice TDD, you need to set up a testing environment. JavaScript has several excellent testing frameworks, with Jest and Vitest being the most popular choices.

Choosing a Testing Framework

Jest is the most widely used testing framework for JavaScript. It’s feature-rich, well-documented, and works great for both Node.js and browser code.

Vitest is a faster alternative built on Vite. It’s Jest-compatible and offers better performance, especially for larger projects.

For this guide, we’ll use Jest, but the concepts apply to any testing framework. Check out the Jest cheatsheet and Vitest cheatsheet for framework-specific details.

Installing Jest

# Using npm
npm install --save-dev jest

# Using pnpm (recommended)
pnpm add -D jest

# Using yarn
yarn add --dev jest

Configuring Jest

Create a jest.config.js file in your project root:

module.exports = {
  // Test environment
  testEnvironment: "node", // or 'jsdom' for browser code

  // File patterns to test
  testMatch: ["**/__tests__/**/*.js", "**/?(*.)+(spec|test).js"],

  // Coverage settings
  collectCoverageFrom: ["src/**/*.js", "!src/**/*.test.js"],

  // Coverage thresholds
  coverageThresholds: {
    global: {
      branches: 80,
      functions: 80,
      lines: 80,
      statements: 80,
    },
  },

  // Module resolution
  moduleFileExtensions: ["js", "json"],

  // Setup files
  setupFilesAfterEnv: ["<rootDir>/jest.setup.js"],
};

Package.json Scripts

Add test scripts to your package.json:

{
  "scripts": {
    "test": "jest",
    "test:watch": "jest --watch",
    "test:coverage": "jest --coverage"
  }
}

Watch Mode for TDD

Watch mode is essential for TDD. It automatically re-runs tests when files change, providing instant feedback:

# Run tests in watch mode
pnpm test:watch

# Or with Jest directly
jest --watch

Watch mode typically offers interactive commands:

a - run all tests
f - run only failed tests
q - quit watch mode
p - filter by filename pattern
t - filter by test name pattern

TDD Workflow: Step-by-Step Guide

Let’s walk through a complete TDD example: building a TodoList class. This will demonstrate the Red-Green-Refactor cycle in action.

Step 1: Write the First Test (Red)

Start with the simplest possible functionality:

describe("TodoList", () => {
  test("should create an empty todo list", () => {
    const todoList = new TodoList();
    expect(todoList.getAll()).toEqual([]);
  });
});

Run the test - it should fail because TodoList doesn’t exist:

pnpm test
# ReferenceError: TodoList is not defined

Step 2: Make It Pass (Green)

Write the minimal code to make the test pass:

class TodoList {
  constructor() {
    this.todos = [];
  }

  getAll() {
    return this.todos;
  }
}

module.exports = TodoList;

The test should now pass! ✅

Step 3: Add Another Test (Red)

Add the next piece of functionality:

test("should add a todo item", () => {
  const todoList = new TodoList();
  todoList.add("Buy groceries");
  expect(todoList.getAll()).toHaveLength(1);
  expect(todoList.getAll()[0].text).toBe("Buy groceries");
});

This test fails because add method doesn’t exist.

Step 4: Make It Pass (Green)

Implement the add method:

class TodoList {
  constructor() {
    this.todos = [];
  }

  getAll() {
    return this.todos;
  }

  add(text) {
    this.todos.push({ text, completed: false });
  }
}

Test passes! ✅

Step 5: Refactor

Now that we have passing tests, let’s refactor. Notice that we’re creating todo objects manually. Let’s improve this:

class TodoList {
  constructor() {
    this.todos = [];
  }

  getAll() {
    return [...this.todos]; // Return a copy to prevent external mutation
  }

  add(text) {
    if (!text || typeof text !== "string") {
      throw new Error("Todo text must be a non-empty string");
    }
    this.todos.push({
      id: Date.now(), // Add unique ID
      text: text.trim(),
      completed: false,
      createdAt: new Date(),
    });
  }
}

All tests still pass! ✅ The refactoring improved the code without breaking functionality.

Step 6: Continue the Cycle

Continue adding features one test at a time:

// Red: Write failing test
test('should mark todo as completed', () => {
  const todoList = new TodoList();
  todoList.add('Buy groceries');
  todoList.complete(0);
  expect(todoList.getAll()[0].completed).toBe(true);
});

// Green: Implement
complete(index) {
  if (index < 0 || index >= this.todos.length) {
    throw new Error('Invalid todo index');
  }
  this.todos[index].completed = true;
}

// Refactor: Use ID instead of index
complete(id) {
  const todo = this.todos.find(t => t.id === id);
  if (!todo) {
    throw new Error('Todo not found');
  }
  todo.completed = true;
}

This iterative approach ensures each feature is tested and working before moving to the next.

Writing Good Tests First

Writing tests first is only valuable if the tests themselves are well-written. Good tests in TDD follow specific principles.

Test Structure: AAA Pattern

The Arrange-Act-Assert (AAA) pattern structures tests clearly:

test("should calculate total price with tax", () => {
  // Arrange: Set up test data and conditions
  const price = 100;
  const taxRate = 0.1;
  const calculator = new PriceCalculator();

  // Act: Execute the code under test
  const total = calculator.calculateTotal(price, taxRate);

  // Assert: Verify the result
  expect(total).toBe(110);
});

Writing Descriptive Test Names

Test names should clearly describe what is being tested:

// ❌ Bad: Vague test name
test('works', () => { ... });

// ❌ Bad: Implementation details
test('calls validateUser with email', () => { ... });

// ✅ Good: Describes behavior
test('should throw error when email is invalid', () => { ... });

// ✅ Good: Describes scenario
test('should return user when valid credentials provided', () => { ... });

Testing Behavior, Not Implementation

TDD tests should focus on behavior, not implementation details:

// ❌ Bad: Testing implementation
test("should call fetch API", () => {
  const userService = new UserService();
  userService.getUser(1);
  expect(fetch).toHaveBeenCalled();
});

// ✅ Good: Testing behavior
test("should return user data when user exists", async () => {
  const userService = new UserService();
  const user = await userService.getUser(1);
  expect(user).toEqual({ id: 1, name: "John Doe" });
});

One Assertion Per Test (When Possible)

While not always practical, one assertion per test makes failures clearer:

// ❌ Less clear: Multiple assertions
test("should validate user", () => {
  const user = validateUser({ email: "test@example.com", age: 25 });
  expect(user.email).toBe("test@example.com");
  expect(user.age).toBe(25);
  expect(user.valid).toBe(true);
});

// ✅ Clearer: Focused tests
test("should accept valid email format", () => {
  const result = validateUser({ email: "test@example.com" });
  expect(result.email).toBe("test@example.com");
});

test("should accept valid age", () => {
  const result = validateUser({ age: 25 });
  expect(result.age).toBe(25);
});

test("should mark user as valid when all fields are correct", () => {
  const result = validateUser({ email: "test@example.com", age: 25 });
  expect(result.valid).toBe(true);
});

Testing Edge Cases

TDD encourages thinking about edge cases early:

describe("divide", () => {
  test("should divide two positive numbers", () => {
    expect(divide(10, 2)).toBe(5);
  });

  test("should handle division by zero", () => {
    expect(() => divide(10, 0)).toThrow("Cannot divide by zero");
  });

  test("should handle negative numbers", () => {
    expect(divide(-10, 2)).toBe(-5);
  });

  test("should handle decimal results", () => {
    expect(divide(1, 3)).toBeCloseTo(0.333, 3);
  });
});

TDD Patterns and Techniques

Several patterns and techniques make TDD more effective. Understanding these will help you write better tests and code.

🔍 Test Doubles: Mocks, Stubs, and Spies

Test doubles replace real dependencies with controllable alternatives:

Mocks: Objects that record method calls and can verify interactions:

// Mocking a database service
const mockDb = {
  save: jest.fn(),
  find: jest.fn(),
};

test("should save user to database", () => {
  const userService = new UserService(mockDb);
  userService.createUser({ name: "John" });

  expect(mockDb.save).toHaveBeenCalledWith(
    expect.objectContaining({ name: "John" }),
  );
});

Stubs: Objects that return predefined values:

// Stubbing an API call
const mockApi = {
  fetchUser: jest.fn().mockResolvedValue({ id: 1, name: "John" }),
};

test("should fetch and return user", async () => {
  const userService = new UserService(mockApi);
  const user = await userService.getUser(1);

  expect(user).toEqual({ id: 1, name: "John" });
});

Spies: Track function calls without replacing behavior:

// Spying on a method
const calculator = new Calculator();
const addSpy = jest.spyOn(calculator, "add");

calculator.calculate(2, 3);
expect(addSpy).toHaveBeenCalledWith(2, 3);

💡 Dependency Injection

Dependency injection makes code testable by allowing you to inject test doubles:

// ❌ Hard to test: Hard-coded dependency
class UserService {
  constructor() {
    this.db = new Database(); // Hard to test
  }
}

// ✅ Testable: Dependency injection
class UserService {
  constructor(db) {
    this.db = db; // Can inject mock
  }
}

// In tests
const mockDb = { save: jest.fn() };
const userService = new UserService(mockDb);

🔍 Fake Objects

Fake objects are working implementations with simplified behavior:

// Fake in-memory database for testing
class FakeDatabase {
  constructor() {
    this.data = {};
  }

  save(key, value) {
    this.data[key] = value;
  }

  find(key) {
    return this.data[key] || null;
  }
}

// Use in tests
test("should save and retrieve user", () => {
  const db = new FakeDatabase();
  const userService = new UserService(db);

  userService.createUser({ id: 1, name: "John" });
  const user = userService.getUser(1);

  expect(user.name).toBe("John");
});

💡 Test Data Builders

Test data builders simplify creating test objects:

class UserBuilder {
  constructor() {
    this.user = {
      id: 1,
      name: "John Doe",
      email: "john@example.com",
      age: 30,
    };
  }

  withEmail(email) {
    this.user.email = email;
    return this;
  }

  withAge(age) {
    this.user.age = age;
    return this;
  }

  build() {
    return { ...this.user };
  }
}

// Usage in tests
test("should validate user email", () => {
  const user = new UserBuilder().withEmail("invalid-email").build();

  expect(() => validateUser(user)).toThrow("Invalid email");
});

TDD with Different Code Types

TDD principles apply to all types of code, but the approach varies slightly. Let’s explore TDD for different scenarios.

TDD for Pure Functions

Pure functions are the easiest to test with TDD:

// 🔴 Red: Write failing test
describe("calculateDiscount", () => {
  test("should apply 10% discount for orders over $100", () => {
    expect(calculateDiscount(150, 0.1)).toBe(135);
  });
});

// 🟢 Green: Implement
function calculateDiscount(price, discountRate) {
  return price * (1 - discountRate);
}

// 🔵 Refactor: Add validation
function calculateDiscount(price, discountRate) {
  if (price < 0) throw new Error("Price must be positive");
  if (discountRate < 0 || discountRate > 1) {
    throw new Error("Discount rate must be between 0 and 1");
  }
  return price * (1 - discountRate);
}

TDD for Classes and Objects

Classes require thinking about state and behavior:

// 🔴 Red: Test class behavior
describe("ShoppingCart", () => {
  test("should start with empty cart", () => {
    const cart = new ShoppingCart();
    expect(cart.getTotal()).toBe(0);
    expect(cart.getItemCount()).toBe(0);
  });

  test("should add item to cart", () => {
    const cart = new ShoppingCart();
    cart.addItem({ id: 1, name: "Product", price: 10 });
    expect(cart.getItemCount()).toBe(1);
    expect(cart.getTotal()).toBe(10);
  });
});

// 🟢 Green: Implement class
class ShoppingCart {
  constructor() {
    this.items = [];
  }

  addItem(item) {
    this.items.push(item);
  }

  getTotal() {
    return this.items.reduce((sum, item) => sum + item.price, 0);
  }

  getItemCount() {
    return this.items.length;
  }
}

TDD for Async Code

Async code requires special handling in tests:

// 🔴 Red: Test async behavior
describe("UserService", () => {
  test("should fetch user by ID", async () => {
    const userService = new UserService();
    const user = await userService.getUser(1);
    expect(user).toEqual({ id: 1, name: "John" });
  });
});

// 🟢 Green: Implement async function
class UserService {
  async getUser(id) {
    const response = await fetch(`/api/users/${id}`);
    return response.json();
  }
}

// Use mocks for testing
test("should fetch user by ID", async () => {
  global.fetch = jest.fn().mockResolvedValue({
    json: async () => ({ id: 1, name: "John" }),
  });

  const userService = new UserService();
  const user = await userService.getUser(1);

  expect(user).toEqual({ id: 1, name: "John" });
  expect(fetch).toHaveBeenCalledWith("/api/users/1");
});

TDD for React Components

TDD works great with React components using React Testing Library:

// 🔴 Red: Test component behavior
import { render, screen } from "@testing-library/react";
import userEvent from "@testing-library/user-event";

describe("Button", () => {
  test("should call onClick when clicked", async () => {
    const handleClick = jest.fn();
    render(<Button onClick={handleClick}>Click me</Button>);

    const button = screen.getByRole("button", { name: /click me/i });
    await userEvent.click(button);

    expect(handleClick).toHaveBeenCalledTimes(1);
  });
});

// 🟢 Green: Implement component
function Button({ onClick, children }) {
  return <button onClick={onClick}>{children}</button>;
}

TDD for API Routes

TDD for API routes involves testing request/response handling:

// 🔴 Red: Test API endpoint
describe("POST /api/users", () => {
  test("should create a new user", async () => {
    const response = await request(app)
      .post("/api/users")
      .send({ name: "John", email: "john@example.com" })
      .expect(201);

    expect(response.body).toMatchObject({
      id: expect.any(Number),
      name: "John",
      email: "john@example.com",
    });
  });
});

// 🟢 Green: Implement route handler
app.post("/api/users", async (req, res) => {
  const { name, email } = req.body;
  const user = await db.users.create({ name, email });
  res.status(201).json(user);
});

Benefits of Test-Driven Development

TDD offers numerous benefits that make it worth the initial learning curve.

✅ Better Code Design

Writing tests first forces you to think about how code will be used, leading to better APIs:

// TDD encourages thinking about usage first
// Test shows desired API:
expect(calculator.add(2, 3)).toBe(5);

// This leads to simple, focused functions
// rather than complex, multi-purpose functions

✅ Comprehensive Test Coverage

Since tests come first, coverage is naturally high. Every feature has tests because features don’t exist without tests.

✅ Living Documentation

Tests serve as executable documentation showing how code should be used:

// Tests document expected behavior
describe("EmailValidator", () => {
  test("should accept valid email addresses", () => {
    expect(EmailValidator.validate("user@example.com")).toBe(true);
  });

  test("should reject emails without @ symbol", () => {
    expect(EmailValidator.validate("invalid-email")).toBe(false);
  });

  test("should reject emails without domain", () => {
    expect(EmailValidator.validate("user@")).toBe(false);
  });
});

✅ Confidence in Refactoring

With comprehensive tests, you can refactor fearlessly:

// Original implementation
function calculateTotal(items) {
  let total = 0;
  for (let i = 0; i < items.length; i++) {
    total += items[i].price;
  }
  return total;
}

// Refactored version - tests ensure it still works
function calculateTotal(items) {
  return items.reduce((sum, item) => sum + item.price, 0);
}

// All tests still pass ✅

✅ Faster Debugging

When tests fail, you know exactly what broke and where:

# Clear failure message
FAIL  __tests__/Calculator.test.js
  ✕ should add two numbers (5ms)

  ● Calculator › should add two numbers

    expect(received).toBe(expected)

    Expected: 5
    Received: 6

    at Object.<anonymous> (__tests__/Calculator.test.js:5:15)

✅ Prevents Over-Engineering

TDD’s “minimum code to pass” principle prevents adding unnecessary features:

// ❌ Without TDD: Might add features you don't need
function add(a, b, options = {}) {
  // Rounding? Formatting? Logging? Who knows what we'll need!
  const result = a + b;
  if (options.round) { ... }
  if (options.format) { ... }
  return result;
}

// ✅ With TDD: Only add what tests require
function add(a, b) {
  return a + b;
}
// Add features only when tests require them

Common Challenges and Solutions

TDD has a learning curve. Here are common challenges and how to overcome them.

Challenge 1: “I Don’t Know What to Test First”

Solution: Start with the simplest, most obvious behavior:

// Start here: What's the simplest thing this code should do?
test("should exist", () => {
  expect(MyClass).toBeDefined();
});

// Then: What's the next simplest thing?
test("should create an instance", () => {
  const instance = new MyClass();
  expect(instance).toBeInstanceOf(MyClass);
});

Challenge 2: “Tests Are Too Slow”

Solution: Use test doubles and focus on unit tests:

// ❌ Slow: Real API calls
test("should fetch user", async () => {
  const user = await realApi.getUser(1); // Slow!
});

// ✅ Fast: Mock API calls
test("should fetch user", async () => {
  const mockApi = { getUser: jest.fn().mockResolvedValue({ id: 1 }) };
  const user = await mockApi.getUser(1); // Fast!
});

Challenge 3: “I Can’t Test Private Methods”

Solution: Test through public interfaces. If you need to test private behavior, it might be a sign to extract it:

// ❌ Trying to test private method
class UserService {
  #validateEmail(email) { ... } // Private - can't test directly
}

// ✅ Test through public interface
class UserService {
  createUser(userData) {
    this.#validateEmail(userData.email); // Tested indirectly
    // ...
  }
}

// Or extract to testable function
function validateEmail(email) { ... } // Can test directly

class UserService {
  createUser(userData) {
    validateEmail(userData.email); // Uses extracted function
  }
}

Challenge 4: “TDD Slows Me Down”

Solution: TDD feels slower initially but saves time long-term. Focus on the Red-Green-Refactor rhythm:

// The rhythm becomes natural:
// 1. Write test (30 seconds)
// 2. Make it pass (1 minute)
// 3. Refactor (30 seconds)
// Total: 2 minutes for a feature

// vs. writing code then debugging (could be 10+ minutes)

Challenge 5: “My Tests Break When I Refactor”

Solution: This might indicate tests are too coupled to implementation. Focus on behavior:

// ❌ Too coupled: Breaks when implementation changes
test("should call setState", () => {
  const component = render(<Component />);
  expect(component.instance().setState).toHaveBeenCalled();
});

// ✅ Behavior-focused: Survives refactoring
test("should update display when button clicked", () => {
  const { getByRole, getByText } = render(<Component />);
  fireEvent.click(getByRole("button"));
  expect(getByText("Updated")).toBeInTheDocument();
});

TDD Best Practices

Following these best practices will make your TDD experience more effective and enjoyable.

✅ Write Tests Before Every Feature

Make TDD a habit. Every new feature starts with a test:

// New feature? Write test first!
test("should calculate shipping cost", () => {
  // Test drives the implementation
});

✅ Keep Tests Fast

Fast tests encourage running them frequently:

// Use mocks for slow operations
const mockDb = {
  save: jest.fn(), // Fast mock instead of real database
};

✅ Keep Tests Independent

Tests should not depend on each other:

// ❌ Bad: Tests depend on execution order
let counter = 0;
test("first test", () => {
  counter = 1;
});
test("second test", () => {
  expect(counter).toBe(1); // Depends on first test
});

// ✅ Good: Each test is independent
test("should increment counter", () => {
  const counter = new Counter();
  counter.increment();
  expect(counter.value).toBe(1);
});

✅ Use Descriptive Test Names

Test names should read like documentation:

// ✅ Good: Clear what's being tested
test("should throw error when email format is invalid", () => {
  // ...
});

test("should return user object when valid credentials provided", () => {
  // ...
});

✅ Refactor in Green Phase

Only refactor when all tests are green:

// ✅ Safe refactoring
test("should add numbers", () => {
  expect(add(2, 3)).toBe(5); // Green ✅
});

// Now safe to refactor
function add(...numbers) {
  return numbers.reduce((a, b) => a + b, 0);
}

// Still green ✅

✅ Delete Tests That Don’t Add Value

Not all tests are valuable. Remove redundant or trivial tests:

// ❌ Trivial test - doesn't add value
test("should be a function", () => {
  expect(typeof myFunction).toBe("function");
});

// ✅ Valuable test - verifies behavior
test("should return correct result", () => {
  expect(myFunction(2, 3)).toBe(5);
});

When Not to Use TDD

TDD is powerful, but it’s not always the right choice. Understanding when not to use TDD is as important as knowing when to use it.

⚠️ Exploratory Programming

When exploring new APIs or libraries, writing code first can be more effective:

// Exploring a new library - code first makes sense
const result = await someNewLibrary.doSomething();
console.log(result); // See what happens

// Once you understand it, then write tests

⚠️ Prototyping and Proof of Concepts

Rapid prototyping often benefits from code-first approach:

// Prototype: Get something working quickly
// Tests can come later when you know what you're building

⚠️ Simple Scripts and One-Off Code

For throwaway scripts or one-time utilities, TDD might be overkill:

// Simple data transformation script
// Probably doesn't need TDD

⚠️ UI That Changes Frequently

UI that’s still being designed might change too frequently for TDD:

// UI in flux - tests might need constant updates
// Consider TDD once design stabilizes

⚠️ Legacy Code Without Tests

Adding tests to legacy code can be challenging. Consider writing characterization tests first:

// Legacy code: Write tests to understand behavior first
// Then refactor with confidence

When TDD Makes Sense

TDD is most valuable for:

Business logic: Core functionality that must work correctly
APIs and libraries: Code that others will use
Complex algorithms: Code where correctness is critical
Refactoring targets: Code you want to improve safely

Conclusion

Test-Driven Development is a powerful methodology that transforms how you write code. By following the Red-Green-Refactor cycle, you create better-designed, more reliable software with comprehensive test coverage.

The key takeaways from this guide:

Start with tests: Write failing tests first to drive design and ensure coverage
Follow the cycle: Red (failing test) → Green (make it pass) → Refactor (improve)
Keep tests focused: Test behavior, not implementation
Refactor safely: Use tests as a safety net when improving code
Know when to use TDD: It’s powerful but not always the right tool

TDD requires practice to master. Start small with simple functions, gradually work up to more complex code, and don’t be discouraged if it feels slow initially. The benefits—better design, fewer bugs, and confidence in refactoring—make the investment worthwhile.

To continue learning about testing, check out our guide on testing strategies for modern web applications, which covers unit testing, integration testing, and end-to-end testing in depth. For framework-specific details, refer to the Jest cheatsheet and Vitest cheatsheet.

Remember: TDD is a skill that improves with practice. Start incorporating it into your workflow today, and you’ll soon see the benefits in code quality and developer confidence.

Table of Contents