TDD Tutorial: Test-Driven Development in Practice 2026

Test-Driven Development (TDD) has become essential for modern software teams. This practical guide walks you through implementing TDD effectively, with real code examples and actionable strategies for 2026 development workflows.

Why Testing Matters

The Cost of Bugs

Bugs discovered in production cost 15-20x more to fix than those caught during development. TDD catches defects early, reducing overall project costs and improving code quality.

Confidence in Refactoring

When you have comprehensive tests, refactoring becomes safe. You can improve code structure without fear of breaking functionality. This leads to cleaner, more maintainable codebases over time.

Documentation Through Tests

Tests serve as living documentation. They show exactly how your code should behave, making onboarding new developers faster and reducing misunderstandings about requirements.

Design Improvement

Writing tests first forces you to think about your code's interface before implementation. This naturally leads to better API design and more modular, testable code.

Getting Started

The TDD Cycle: Red-Green-Refactor

TDD follows a simple three-step cycle:

1. Red: Write a failing test for functionality that doesn't exist yet
2. Green: Write minimal code to make the test pass
3. Refactor: Improve the code while keeping tests passing

This cycle ensures you only write code that's actually needed and that everything is tested.

Setting Up Your Environment

JavaScript/Node.js:

npm install --save-dev jest

Python:

pip install pytest

Java:

# Maven
mvn archetype:generate -DgroupId=com.example -DartifactId=tdd-project

C#/.NET:

dotnet new xunit -n TddProject

Configure your test runner to watch files and re-run tests on changes. Most modern frameworks support this out of the box.

Writing Effective Tests

Test Structure: Arrange-Act-Assert

Every test should follow this pattern:

describe('UserService', () => {
  it('should calculate user discount correctly', () => {
    // Arrange: Set up test data
    const user = { id: 1, memberSince: 2020, totalSpent: 5000 };
    const userService = new UserService();

    // Act: Execute the function being tested
    const discount = userService.calculateDiscount(user);

    // Assert: Verify the result
    expect(discount).toBe(0.15); // 15% for 4+ year members
  });
});

Naming Conventions

Write test names that describe behavior, not implementation:

// ✅ Good
it('should return 15% discount for members of 4+ years')

// ❌ Poor
it('test discount calculation')

Test Isolation

Each test must be independent:

import pytest

class TestPaymentProcessor:
    @pytest.fixture(autouse=True)
    def setup(self):
        # Fresh instance for each test
        self.processor = PaymentProcessor()
        self.test_card = "4111111111111111"
        yield
        # Cleanup if needed

    def test_valid_payment_succeeds(self):
        result = self.processor.charge(self.test_card, 100)
        assert result.status == "success"

    def test_invalid_card_fails(self):
        result = self.processor.charge("invalid", 100)
        assert result.status == "failed"

Mocking External Dependencies

Isolate the code under test by mocking external services:

describe('OrderService', () => {
  it('should send confirmation email after order', async () => {
    // Mock the email service
    const emailService = {
      send: jest.fn().mockResolvedValue({ success: true })
    };

    const orderService = new OrderService(emailService);
    await orderService.createOrder({ items: ['book'], email: 'user@example.com' });

    // Verify email was called correctly
    expect(emailService.send).toHaveBeenCalledWith(
      expect.objectContaining({ to: 'user@example.com' })
    );
  });
});

Real Examples

Example 1: Shopping Cart Calculator

Step 1: Write the failing test (Red)

describe('ShoppingCart', () => {
  it('should calculate total with tax', () => {
    const cart = new ShoppingCart();
    cart.addItem({ name: 'Laptop', price: 1000, quantity: 1 });
    cart.addItem({ name: 'Mouse', price: 25, quantity: 2 });

    const total = cart.getTotal(0.08); // 8% tax
    expect(total).toBe(1108); // (1000 + 50) * 1.08
  });
});

Step 2: Write minimal code (Green)

class ShoppingCart {
  constructor() {
    this.items = [];
  }

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

  getTotal(taxRate) {
    const subtotal = this.items.reduce((sum, item) => {
      return sum + (item.price * item.quantity);
    }, 0);
    return subtotal * (1 + taxRate);
  }
}

Step 3: Refactor (Refactor)

class ShoppingCart {
  constructor() {
    this.items = [];
  }

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

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

  getTotal(taxRate) {
    return this.getSubtotal() * (1 + taxRate);
  }
}

Example 2: User Authentication

import pytest
from unittest.mock import Mock, patch

class TestUserAuthentication:
    @pytest.fixture
    def auth_service(self):
        return AuthenticationService()

    def test_login_with_valid_credentials(self, auth_service):
        user = auth_service.login("user@example.com", "password123")
        assert user.email == "user@example.com"
        assert user.is_authenticated is True

    def test_login_with_invalid_password_fails(self, auth_service):
        with pytest.raises(AuthenticationError):
            auth_service.login("user@example.com", "wrongpassword")

    def test_password_reset_sends_email(self, auth_service):
        with patch('auth_service.email_service') as mock_email:
            auth_service.request_password_reset("user@example.com")
            mock_email.send.assert_called_once()

Best Practices

1. Test Behavior, Not Implementation

// ✅ Good: Tests the behavior
it('should prevent duplicate emails', () => {
  const userRepo = new UserRepository();
  userRepo.create({ email: 'test@example.com' });

  expect(() => userRepo.create({ email: 'test@example.com' }))
    .toThrow('Email already exists');
});

// ❌ Poor: Tests implementation details
it('should call validateEmail function', () => {
  expect(validateEmail).toHaveBeenCalled();
});

2. Keep Tests Simple and Focused

Each test should verify one behavior:

// ✅ Good: One assertion per test
it('should calculate discount for premium members', () => {
  expect(calculateDiscount('premium')).toBe(0.20);
});

it('should calculate discount for regular members', () => {
  expect(calculateDiscount('regular')).toBe(0.05);
});

// ❌ Poor: Multiple behaviors in one test
it('should calculate discounts', () => {
  expect(calculateDiscount('premium')).toBe(0.20);
  expect(calculateDiscount('regular')).toBe(0.05);
  expect(calculateDiscount('vip')).toBe(0.30);
});

3. Use Descriptive Assertions

// ✅ Good
expect(response.statusCode).toBe(200);
expect(user.email).toMatch(/^[^\s@]+@[^\s@]+\.[^\s@]+$/);

// ❌ Poor
expect(response).toBe(true);

4. Test Edge Cases

describe('calculateAge', () => {
  it('should handle leap year birthdays', () => {
    const age = calculateAge('2000-02-29', '2024-02-28');
    expect(age).toBe(23);
  });

  it('should handle future dates gracefully', () => {
    expect(() => calculateAge('2025-01-01', '2024-01-01'))
      .toThrow('Birth date cannot be in the future');
  });
});

Common Pitfalls

1. Testing Implementation Instead of Behavior

Problem: Tests break when you refactor, even though behavior stays the same.

Solution: Focus on what the code does, not how it does it.

2. Flaky Tests

Problem: Tests pass sometimes, fail other times.

Solution: Avoid time-dependent tests, use fixed data, mock external services.

// ❌ Flaky
it('should process within 100ms', (done) => {
  setTimeout(() => {
    expect(true).toBe(true);
    done();
  }, 50);
});

// ✅ Reliable
it('should process the queue', () => {
  const queue = new Queue();
  queue.add('item');
  expect(queue.process()).toBe('item');
});

3. Over-Mocking

Problem: Mocking too much makes tests unrealistic.

Solution: Mock only external dependencies, test real logic.

4. Skipping Tests

Problem: Commented-out or skipped tests accumulate.

Solution: Fix failing tests immediately or create a ticket.

// ❌ Don't do this
// it('should handle concurrent requests', () => { ... });

// ✅ Do this instead
it.todo('should handle concurrent requests');

Integration with CI/CD

GitHub Actions Example

name: Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '18'
      - run: npm install
      - run: npm test -- --coverage
      - uses: codecov/codecov-action@v3
        with:
          files: ./coverage/lcov.info

Coverage Requirements

Set minimum coverage thresholds:

{
  "jest": {
    "collectCoverageFrom": ["src/**/*.js"],
    "coverageThreshold": {
      "global": {
        "branches": 80,
        "functions": 80,
        "lines": 80,
        "statements": 80
      }
    }
  }
}

Pre-commit Hooks

npm install --save-dev husky lint-staged

npx husky install
npx husky add .husky/pre-commit "npm test"

Summary

Test-Driven Development is a powerful practice that improves code quality, reduces bugs, and makes refactoring safe. Start with the red-green-refactor cycle, write focused tests with clear assertions, and integrate testing into your CI/CD pipeline.

Key Takeaways:

• Write tests before implementation
• Follow Arrange-Act-Assert structure
• Test behavior, not implementation
• Keep tests isolated and independent
• Mock external dependencies
• Integrate tests into CI/CD
• Maintain high coverage standards
• Fix failing tests immediately

By adopting TDD practices in 2026, you'll build more reliable, maintainable software that scales with your team's growth.