Tdd Guide

TDD Guide is an AI skill that provides practical guidance for applying Test-Driven Development in real software projects. It covers the red-green-refactor cycle, test design principles, mocking strategies, TDD with different architectures, and common pitfalls that help developers build higher quality code through test-first development.

What Is This?

Overview

TDD Guide delivers actionable TDD practices that work in production codebases, not just textbook examples. It addresses the red-green-refactor cycle with realistic examples showing each phase, test design that drives good software architecture through interface-first thinking, mocking strategies that balance test isolation with integration confidence, TDD application in web APIs, frontend components, and data pipelines, refactoring techniques that improve code while keeping tests green, and guidance for adopting TDD incrementally in teams that do not currently practice it.

Who Should Use This

This skill serves developers learning TDD who want practical rather than theoretical guidance, teams adopting test-first practices and needing real-world examples, senior engineers evaluating whether TDD fits their project's needs, and technical coaches introducing TDD to development teams.

Why Use It?

Problems It Solves

Code written without tests is difficult to refactor and accumulates design issues. Tests written after implementation often test implementation details rather than behavior, making them brittle. Developers who try TDD without guidance write tests that are too detailed, too slow, or test the wrong things, leading them to abandon the practice.

Core Highlights

The skill demonstrates TDD with realistic scenarios rather than trivial calculator examples. Each phase of red-green-refactor includes clear guidance on what to do and what to avoid. Mocking guidance prevents over-mocking that undermines test value. Architecture-aware TDD shows how test-first development naturally produces clean interfaces.

How to Use It?

Basic Usage

import pytest

def test_order_calculates_total_with_discount():
    order = Order()
    order.add_item("Widget", price=100, quantity=2)
    order.apply_discount(percent=10)
    assert order.total == 180.0  # 200 - 10%

class Order:
    def __init__(self):
        self.items = []
        self.discount_percent = 0

    def add_item(self, name, price, quantity):
        self.items.append({"name": name, "price": price, "quantity": quantity})

    def apply_discount(self, percent):
        self.discount_percent = percent

    @property
    def total(self):
        subtotal = sum(i["price"] * i["quantity"] for i in self.items)
        return subtotal * (1 - self.discount_percent / 100)

Real-World Examples

import pytest
from unittest.mock import AsyncMock

class TestUserRegistration:
    @pytest.fixture
    def service(self):
        repo = AsyncMock()
        emailer = AsyncMock()
        return UserService(repo, emailer), repo, emailer

    @pytest.mark.asyncio
    async def test_registers_new_user(self, service):
        svc, repo, emailer = service
        repo.find_by_email.return_value = None
        repo.save.return_value = User(id=1, email="new@test.com")

        result = await svc.register("new@test.com", "password123")

        assert result.id == 1
        repo.save.assert_called_once()
        emailer.send_welcome.assert_called_once_with("new@test.com")

    @pytest.mark.asyncio
    async def test_rejects_duplicate_email(self, service):
        svc, repo, emailer = service
        repo.find_by_email.return_value = User(id=1, email="exists@test.com")

        with pytest.raises(DuplicateEmailError):
            await svc.register("exists@test.com", "password123")
        repo.save.assert_not_called()
        emailer.send_welcome.assert_not_called()

Advanced Tips

Start each TDD session by listing the test cases you expect to write before writing any code. This outside-in approach clarifies the interface before implementation. When a test is hard to write, treat it as design feedback indicating the interface may need simplification. Use the "transformation priority premise" to guide the order of test cases from simple to complex.

When to Use It?

Use Cases

Use TDD Guide when building new features where the interface is not yet defined, when working on complex business logic that benefits from specification through tests, when refactoring existing code and wanting a safety net of tests first, or when teaching a team test-first practices.

Related Topics

Unit testing frameworks, behavior-driven development, refactoring techniques, SOLID design principles, and continuous integration practices all complement TDD workflows.

Important Notes

Requirements

A testing framework configured for the project's language. Understanding of the feature requirements to write meaningful test cases. Willingness to write tests before implementation code.

Usage Recommendations

Do: write the simplest test that fails for the right reason, then write the simplest code that passes. Refactor aggressively in the refactor phase while all tests are green. Test behavior and outcomes rather than implementation details.

Don't: skip the refactor phase, as this is where TDD produces clean design. Write tests that are so specific they break on any implementation change. Mock everything to the point where tests only verify mock configuration.

Limitations

TDD is most effective for business logic and less applicable to UI layout, integration code, and exploratory prototyping. The discipline required to always write tests first is challenging to maintain under deadline pressure. Test-first development can feel slower initially, though it typically reduces total development time by catching issues earlier.