测试驱动开发(TDD)：红绿重构循环实战

Python 测试与调试专题 · 先测试后代码的开发方法论

专题：Python 测试与调试系统学习 · 测试覆盖率与质量度量篇

关键词：Python, 测试, 调试, TDD, 测试驱动开发, 红绿重构, 敏捷开发, 先测试后代码, Python

一、TDD概述

测试驱动开发（Test-Driven Development，简称TDD）是Kent Beck在极限编程（Extreme Programming）中提出的一种软件开发方法论，其核心信条是"先写测试，后写代码"。与传统开发流程——先写实现代码再补测试——截然相反，TDD要求开发者在编写任何生产代码之前，先编写一个会失败的单元测试。这个看似简单的反转，带来了软件设计、质量和工作流程上的根本性变化。

TDD由三条定律构成，被称为"TDD三定律"，由Robert C. Martin（Uncle Bob）在其著作《Clean Code》中系统阐述：第一定律，在编写失败的单元测试之前，不允许编写任何生产代码；第二定律，只编写刚好足以使测试失败的单元测试量（编译失败也算失败）；第三定律，只编写刚好足以通过当前失败测试的生产代码量。这三条定律共同构成了TDD的严格节奏，将开发过程切分为数十秒到数分钟的小循环，每个循环都产生一个经过验证的增量。

与传统测试相比，TDD有本质区别：传统测试是验证已存在的代码，目标是发现缺陷；而TDD是驱动代码的设计，目标是创建可测试、低耦合、高内聚的系统。Kent Beck曾将TDD总结为两个核心原则：一是"确保代码有事可做"（测试先于代码），二是"消除重复"（重构去除冗余）。TDD的收益包括：显著降低缺陷率（诸多研究表明可降低40%-80%）、改善代码设计（因为可测试性强制解耦）、提供安全的回归测试覆盖、以及充当活文档。然而TDD也面临挑战：学习曲线陡峭、初期速度慢、需要团队共识、对遗留代码难以直接应用等。

TDD与传统测试流程对比

维度	传统开发流程	TDD流程
测试时机	编码完成后	编码开始前
测试目的	验证、发现缺陷	驱动设计、验证行为
反馈周期	数小时到数天	数十秒到数分钟
覆盖完整性	容易遗漏边界	自然覆盖所有路径
代码耦合度	容易紧耦合	强制低耦合
重构安全性	缺乏回归保障	天然安全网

TDD基础示意

以下代码展示TDD循环的最简形式。首先编写失败的测试（红）：

# test_calculator.py — 红阶段：先写一个会失败的测试
def test_add():
    # 此时 Calculator 类还不存在，运行测试会报 ImportError
    calc = Calculator()
    result = calc.add(2, 3)
    assert result == 5

然后编写刚好通过测试的生产代码（绿）：

# calculator.py — 绿阶段：编写刚好通过测试的代码
class Calculator:
    def add(self, a, b):
        return a + b

最后审视代码进行重构（重构）：

# 重构阶段——添加类型提示和文档（不改变行为）
class Calculator:
    """一个简单的计算器，展示TDD基础循环。"""
    def add(self, a: float, b: float) -> float:
        """返回两个数的和。"""
        return a + b

这个最简示例虽然微不足道，但完整呈现了TDD的核心节奏：红（编写失败测试）→ 绿（让测试通过）→ 重构（改善代码质量）。每一个TDD循环都是这个三拍子的舞蹈。

二、红-绿-重构循环

红-绿-重构（Red-Green-Refactor）是TDD执行层面最核心的节奏模式。它将开发过程分解为大量微小、可逆的步骤，每个步骤都始于一个失败的测试，终于一个通过测试的、经过重构的干净代码。这个节奏使得开发者可以始终保持对代码库的高度信心，因为每一次修改都立刻得到验证。

红阶段：编写失败的测试

红阶段的目标是"写一个会失败的测试"——这里的"失败"是指测试未通过，而非测试代码本身出错。失败的测试定义了接下来要编写的功能的确切行为。这个阶段的要点在于：只写一个测试，不要贪多；让测试针对一个明确的行为，而非实现细节；确保测试失败的原因是你预期的（而不是因为测试代码写错了）。实践中，一个好的方式是先思考"我希望这个方法做什么"，而不是"这个方法应该如何实现"。这迫使开发者站在调用者角度设计API，从而产生更自然、更易用的接口。

绿阶段：让测试通过

绿阶段的目标纯粹而简单：用最少的代码让测试变绿。这里的关键是"最少的代码"——新手常犯的错误是在这个阶段就开始考虑"优雅"、"性能"、"通用性"。TDD明确要求绿阶段只求通过，不考虑代码质量。哪怕用硬编码返回一个常量来通过测试也是允许的（虽然下一个测试会迫使你泛化）。这个看似反直觉的约束，实际上保证了测试覆盖的完整性——每一行生产代码都有对应的测试来证明其必要性。如果一段代码没有测试就通过了所有用例，那它就是多余的。

重构阶段：改善代码

重构阶段是在测试全部通过的安全前提下，改善代码的内部结构，而不改变其外部行为。有了绿色测试作为安全网，开发者可以大胆地提取方法、重命名变量、消除重复、简化条件。重构阶段确保代码库保持健康，技术债务不会累积。许多TDD实践者说"重构是TDD中最容易被跳过的阶段"——因为测试通过了，就急着写下一个功能。然而跳过重构恰恰是让代码腐化的起点，会逐步侵蚀TDD带来的设计优势。

增量迭代实例：字符串处理

以下实例展示一个完整的多轮TDD迭代，实现一个字符串反转功能：

# 第1轮：测试反转非空字符串
def test_reverse_normal():
    result = reverse_string("hello")
    assert result == "olleh"

# 实现（绿阶段）：最简单的实现
def reverse_string(s):
    return s[::-1]

# 第2轮：测试空字符串
def test_reverse_empty():
    assert reverse_string("") == ""

# 当前实现已经可以通过，无需改代码

# 第3轮：测试None输入（边界情况）
def test_reverse_none():
    assert reverse_string(None) == ""

# 需要修改实现来处理边界
def reverse_string(s):
    if s is None:
        return ""
    return s[::-1]

每一轮迭代都在扩展功能边界，同时保证之前的所有测试依然通过。这种累积式的增量开发，使得代码库始终处于"已知可工作"的状态，极大地减少了调试时间。

TDD循环的心理学

TDD的节奏设计巧妙利用了心理学原理。红阶段创造了一种"紧张感"——测试在失败，代码不完整，大脑处于警觉状态。绿阶段带来"解脱和满足"——测试通过，成就感释放多巴胺。重构阶段提供"掌控感"——代码变得整洁，结构清晰。这个情绪循环——紧张、满足、掌控——形成一个正向反馈回路，让开发者自然而然地保持专注和动力。许多实践者报告TDD具有某种"成瘾性"——一旦习惯了这个节奏，回到先写代码再测试的方式会感到不安。

三、TDD Katas练习

TDD Kata（型）是一种刻意练习方法，通过反复演练标准化的编程问题，来内化TDD的节奏和技巧。就像武术中的套路练习一样，Kata的目的不是解决实际问题，而是磨炼肌肉记忆和思维方式。以下是几个经典的TDD Kata，每个都展示了TDD在特定场景下的应用模式。

FizzBuzz Kata

FizzBuzz是TDD入门最经典的Kata。规则简单：编写一个程序，输出1到100的数字，但3的倍数输出Fizz，5的倍数输出Buzz，同时是3和5的倍数输出FizzBuzz。这个问题的简单性使得学习者可以专注于TDD节奏本身。

# FizzBuzz — 第1个测试：3的倍数
def test_fizz_when_multiple_of_3():
    assert fizzbuzz(3) == "Fizz"
    assert fizzbuzz(6) == "Fizz"
    assert fizzbuzz(99) == "Fizz"

# 最简单的实现
def fizzbuzz(n):
    if n % 3 == 0:
        return "Fizz"

# FizzBuzz — 第2个测试：5的倍数
def test_buzz_when_multiple_of_5():
    assert fizzbuzz(5) == "Buzz"
    assert fizzbuzz(10) == "Buzz"

# 扩展实现
def fizzbuzz(n):
    if n % 3 == 0 and n % 5 == 0:
        return "FizzBuzz"
    if n % 3 == 0:
        return "Fizz"
    if n % 5 == 0:
        return "Buzz"
    return str(n)

# FizzBuzz — 第3个测试：非倍数返回数字本身
def test_number_when_not_multiple():
    assert fizzbuzz(1) == "1"
    assert fizzbuzz(2) == "2"
    assert fizzbuzz(7) == "7"

# 当前实现已能通过所有测试，可安全重构抽取方法
def _is_multiple(n, divisor):
    return n % divisor == 0

def fizzbuzz(n):
    if _is_multiple(n, 3) and _is_multiple(n, 5):
        return "FizzBuzz"
    if _is_multiple(n, 3):
        return "Fizz"
    if _is_multiple(n, 5):
        return "Buzz"
    return str(n)

字符串计算器Kata

字符串计算器（String Calculator）Kata由Roy Osherove提出，是一个逐步增加复杂度的TDD练习。从一个空字符串返回0开始，逐步支持任意数量数字相加、换行符分隔、自定义分隔符、负数异常等。

# 字符串计算器——逐步TDD
# 第1步：空字符串返回0
def test_empty_string_returns_zero():
    assert add("") == 0

# 第2步：单个数字返回其值
def test_single_number():
    assert add("1") == 1
    assert add("5") == 5

# 第3步：两个逗号分隔的数字求和
def test_two_numbers():
    assert add("1,2") == 3
    assert add("10,20") == 30

# 累积实现
def add(numbers: str) -> int:
    if not numbers:
        return 0
    parts = numbers.split(",")
    return sum(int(p) for p in parts)

# 第4步：支持换行符作为分隔符
def test_newline_as_delimiter():
    assert add("1\n2,3") == 6

# 第5步：支持自定义分隔符（格式: //[delimiter]\n[numbers]）
def test_custom_delimiter():
    assert add("//;\n1;2") == 3

# 实现扩展
import re

def add(numbers: str) -> int:
    if not numbers:
        return 0
    if numbers.startswith("//"):
        delimiter, numbers = numbers[2:].split("\n", 1)
        parts = numbers.replace("\n", "").split(delimiter)
    else:
        parts = numbers.replace("\n", ",").split(",")
    return sum(int(p) for p in parts)

银行账户Kata

银行账户Kata练习的是有状态对象的TDD。通过实现存款、取款、打印账单等功能，学习如何对状态变更和副作用进行测试驱动。这个Kata特别强调了TDD中的"测试行为而非数据"原则。

# 银行账户Kata — 测试存款行为
def test_deposit_increases_balance():
    account = BankAccount()
    account.deposit(100)
    assert account.balance == 100

def test_multiple_deposits():
    account = BankAccount()
    account.deposit(50)
    account.deposit(30)
    assert account.balance == 80

class BankAccount:
    def __init__(self):
        self.balance = 0
    def deposit(self, amount):
        self.balance += amount

Kata练习的核心价值不在于解决问题本身，而在于反复体验TDD的微观节奏。建议每个Kata至少做3-5遍，直到"红-绿-重构"成为本能反应，不再需要刻意思考。许多经验丰富的TDD实践者仍然定期做Kata练习，以保持手感和精进技巧。

四、测试先行设计

TDD最深刻的影响不在于测试，而在于设计。先写测试的约束天然地推动了更好的软件设计——因为可测试性本身就是一种设计质量指标。如果一段代码难以测试，往往意味着它有紧耦合、职责不单一、隐藏依赖等设计问题。TDD通过"测试先行"的纪律，迫使开发者在写任何实现之前，就从调用者的角度思考接口设计。

测试驱动接口设计

当开发者先写测试时，他们实际上是在编写API的第一个使用示例。这个使用示例直接决定了接口的形式：参数是否需要？返回值应该是什么？这个类应该有什么方法？如果测试代码写起来别扭、冗长、不自然，通常说明接口设计有问题。这种即时反馈是TDD对设计最宝贵的贡献——它让你在使用之前就感受到API的"手感"。一个好的TDD实践者会反复调整测试代码，直到API感觉"自然"，然后再开始实现。

可测试性与依赖注入

依赖注入（Dependency Injection）是TDD最重要的盟友之一。当一个类内部直接new了另一个对象（如数据库连接、HTTP客户端），它就无法在测试中被替换为Mock或Stub。TDD强制要求通过构造函数或方法参数传入依赖，这使得代码天然支持依赖注入，从而实现了控制反转（IoC）。

# 不可测试的设计——类内部硬编码依赖
class OrderProcessor:
    def process(self, order):
        db = DatabaseConnection("localhost", "root", "password")
        db.save(order)  # 测试中会真实连接数据库

# 可测试的设计——依赖通过构造函数注入
class OrderProcessor:
    def __init__(self, db_connection):
        self.db = db_connection

    def process(self, order):
        self.db.save(order)

# 测试中可以传入Mock
def test_process_saves_order():
    mock_db = MagicMock()
    processor = OrderProcessor(mock_db)
    processor.process({"id": 1, "total": 100})
    mock_db.save.assert_called_once_with({"id": 1, "total": 100})

SOLID原则与TDD

TDD和SOLID原则之间存在双向强化关系。TDD驱动出符合SOLID的设计，而SOLID原则又使代码更易于测试。具体来说：单一职责原则（SRP）使得每个类只需要一组聚焦的测试；开闭原则（OCP）通过接口抽象允许用Mock替换具体实现；里氏替换原则（LSP）确保Mock的行为与真实实现一致；接口隔离原则（ISP）使得测试只需关注相关的少数方法；依赖反转原则（DIP）直接呼应了TDD对依赖注入的要求。在实践中，TDD和SOLID共同作用，产生的代码具有高度的模块化、低耦合和可测试性。

测试先行设计实例：用户服务

# 先写测试——定义UserService的行为契约
def test_register_user_creates_account():
    repo = MagicMock()
    email_service = MagicMock()
    service = UserService(repo, email_service)

    user = service.register("alice@example.com", "pass123")

    assert user.email == "alice@example.com"
    repo.save.assert_called_once()
    email_service.send_welcome.assert_called_once_with("alice@example.com")

# 接口由测试驱动出来后再实现
class UserService:
    def __init__(self, user_repo, email_service):
        self.repo = user_repo
        self.email_service = email_service

    def register(self, email, password):
        if self.repo.find_by_email(email):
            raise ValueError("Email already registered")
        user = User(id=uuid4(), email=email, password_hash=self._hash(password))
        self.repo.save(user)
        self.email_service.send_welcome(email)
        return user

    def _hash(self, password):
        import hashlib
        return hashlib.sha256(password.encode()).hexdigest()

这个实例清晰地展示了测试如何驱动接口设计：测试代码首先定义了UserService有两个依赖（user_repo和email_service），以及register方法接收email和password并返回User对象。实现代码只是将测试中隐含的设计决策具体化。

五、Mock在TDD中

Mock对象在TDD中扮演着复杂而重要的角色。一方面，Mock是TDD实践中不可或缺的工具——它让开发者可以隔离被测试单元，模拟外部依赖的行为，使测试保持快速和可靠。另一方面，过度使用Mock会导致测试与实现细节过度耦合，使测试变得脆弱——实现重构时测试跟着大片失败。理解何时使用Mock、何时避免Mock，是TDD进阶的核心技能。

TDD中的Mock适度使用

Mock的合理使用场景包括：外部I/O操作（数据库、网络、文件系统）、不可控的第三方服务、耗时操作（如加密计算）、难以构造的状态（如网络超时异常）。Mock的过度使用表现为：对值对象（Value Object）做Mock、对同一类中的私有方法做Mock、对简单的数据结构做Mock。一个很好的判断标准是：如果你的测试在使用Mock三个月后，你记不清Mock的行为设置，说明Mock用得太多。另一个经验法则："不要Mock你不拥有的类型"——对第三方库的类做Mock可能导致升级后行为不一致的风险。

Mock驱动接口定义

TDD中的Mock有一个独特的副效应：它可以驱动出更清晰的接口。当你在测试中写 `mock.save.assert_called_once_with(data)` 时，你实际上是在定义"save方法应该被调用，并且参数是data"这个契约。这个契约反过来要求真实对象提供同样签名的方法。这种"契约优先"的方式，使得接口设计不是从实现角度出发，而是从使用和协作角度出发。

# Mock驱动接口——测试定义契约
def test_notification_service():
    sender = MagicMock()
    service = AlertService(sender)

    service.send_alert("Server down!", level="critical")

    sender.send.assert_called_once_with(
        message="Server down!",
        channel="pagerduty",
        priority=1
    )

# 实现遵循测试定义的接口
class AlertService:
    def __init__(self, sender):
        self.sender = sender

    def send_alert(self, message, level="info"):
        channel_map = {"critical": "pagerduty", "info": "email"}
        priority_map = {"critical": 1, "info": 3}
        self.sender.send(
            message=message,
            channel=channel_map.get(level, "email"),
            priority=priority_map.get(level, 3)
        )

契约测试基础

契约测试（Contract Testing）是解决Mock问题的进阶技术。其核心思想是：Mock设置的"期望行为"应该与真实实现的行为一致，而这个一致性通过一组双方都运行的契约测试来保证。具体做法是：定义一个接口契约测试基类，提供者和消费者都运行它——提供者验证真实实现满足契约，消费者用契约生成Mock以确保Mock行为与真实一致。

# 契约测试——定义接口的行为契约
class UserRepositoryContract:
    """所有UserRepository实现都必须通过这个契约测试。"""
    def test_save_and_find_by_id(self):
        repo = self.build_repo()
        user = User(id="1", name="Alice")
        repo.save(user)
        found = repo.find_by_id("1")
        assert found.name == "Alice"

    def test_find_nonexistent_returns_none(self):
        repo = self.build_repo()
        assert repo.find_by_id("nonexistent") is None

# 真实实现的契约测试
class TestPostgresUserRepository(UserRepositoryContract):
    def build_repo(self):
        return PostgresUserRepository(connection=real_pg_conn())

# Mock消费者也可以用契约来校验
def test_service_with_mock():
    mock_repo = MagicMock(spec=UserRepositoryContract)
    mock_repo.find_by_id.return_value = User(id="1", name="Alice")
    service = UserService(mock_repo)
    result = service.get_user_name("1")
    assert result == "Alice"

契约测试框架（如Pact）将此概念扩展到微服务间的HTTP契约验证，但在单元测试层面，简单的基类继承方式已经能提供很好的保障。关键是确保你的Mock行为与真实行为一致——否则测试虽然通过，但在生产环境中仍然会失败。

六、TDD与Web开发

Web开发是TDD应用的重要战场。HTTP请求/响应模型天然适合测试：输入是请求（参数、头信息、请求体），输出是响应（状态码、响应体、头信息）。然而Web开发中的状态管理（数据库、会话）、模板渲染、异步处理等也带来了测试挑战。本节通过 Flask 和 Django 的实例展示 Web TDD 的实践模式。

Flask TDD实例

Flask的测试客户端使得模拟HTTP请求变得非常方便。TDD流程从编写一个路由测试开始，然后实现路由，再重构。

# Flask TDD — 先写API测试
def test_health_check_returns_ok(client):
    """测试健康检查端点。"""
    response = client.get("/api/health")
    assert response.status_code == 200
    data = response.get_json()
    assert data["status"] == "ok"

def test_create_item(client):
    """测试创建资源。"""
    response = client.post("/api/items", json={"name": "TDD Book", "price": 39.9})
    assert response.status_code == 201
    data = response.get_json()
    assert data["name"] == "TDD Book"
    assert data["price"] == 39.9

# 然后实现Flask路由
from flask import Flask, request, jsonify

app = Flask(__name__)
items = {}

@app.route("/api/health")
def health():
    return jsonify({"status": "ok"})

@app.route("/api/items", methods=["POST"])
def create_item():
    data = request.get_json()
    item_id = str(len(items) + 1)
    items[item_id] = data
    return jsonify({"id": item_id, **data}), 201

Django TDD实例

Django的测试框架基于unittest，提供TestCase类和各种辅助工具。Django社区的TDD实践通常分为单元测试（测试模型方法、表单逻辑）和集成测试（测试视图、API端点）。

# Django TDD — 先写Model测试
from django.test import TestCase
from django.core.exceptions import ValidationError

class ProductModelTest(TestCase):
    def test_product_creation(self):
        product = Product.objects.create(
            name="Test-driven Development",
            price=39.90,
            stock=100
        )
        self.assertEqual(product.name, "Test-driven Development")
        self.assertTrue(product.is_available())

    def test_product_out_of_stock(self):
        product = Product.objects.create(
            name="Out of Stock Item",
            price=10.00,
            stock=0
        )
        self.assertFalse(product.is_available())

    def test_negative_price_raises_error(self):
        with self.assertRaises(ValidationError):
            product = Product(name="Bad", price=-1)
            product.full_clean()

# Django TDD — API视图测试
from rest_framework.test import APITestCase
from rest_framework import status

class ProductAPITest(APITestCase):
    def test_list_products_returns_paginated_results(self):
        Product.objects.create(name="Item 1", price=10, stock=5)
        Product.objects.create(name="Item 2", price=20, stock=3)

        response = self.client.get("/api/products/")

        self.assertEqual(response.status_code, status.HTTP_200_OK)
        self.assertEqual(len(response.data["results"]), 2)

    def test_create_product_without_authentication_fails(self):
        response = self.client.post("/api/products/", {
            "name": "Unauthorized Item", "price": 100, "stock": 1
        })
        self.assertEqual(response.status_code, status.HTTP_401_UNAUTHORIZED)

数据库操作TDD

数据库操作是Web TDD中的难点。核心策略是：在单元测试层面使用Mock隔离数据库，在集成测试层面使用真实测试数据库。对于TDD来说，先写针对数据访问层（Repository）的接口测试，再用Mock替换数据库实现进行业务逻辑测试，最后用集成测试验证真实的数据库交互。

# 数据库TDD策略 — Repository模式加Mock
class OrderRepository:
    def find_by_id(self, order_id): ...
    def save(self, order): ...
    def find_pending_orders(self): ...

# 业务逻辑层使用Mock隔离数据库
def test_cancel_order_marks_as_cancelled():
    repo = MagicMock()
    order = Order(id=1, status="pending")
    repo.find_by_id.return_value = order
    service = OrderService(repo)

    service.cancel_order(1)

    assert order.status == "cancelled"
    repo.save.assert_called_once_with(order)

# Service实现
class OrderService:
    def __init__(self, repo):
        self.repo = repo
    def cancel_order(self, order_id):
        order = self.repo.find_by_id(order_id)
        order.cancel()
        self.repo.save(order)

Web TDD的关键在于分层测试策略：视图层测试关注HTTP协议（状态码、JSON结构），服务层测试关注业务逻辑（规则、计算），数据层测试关注持久化。每一层都有明确的关注点，各层之间通过接口隔离，使得测试可以独立维护和运行。

七、重构技术

重构（Refactoring）是TDD三拍子中的关键一环，也是最容易被忽视的一环。Martin Fowler将重构定义为"在不改变软件外部行为的前提下，改善其内部结构的过程"。在TDD语境下，重构阶段之所以安全，是因为绿阶段的通过测试提供了坚实的回归保护网。没有这个安全网，重构就只是"大规模代码修改"的另一种说法。

安全重构的步骤

TDD中的安全重构遵循严格步骤，每一步都以测试通过为前提：第一步，确认所有测试都是绿的（如果有一项失败，先停下来修复）；第二步，识别需要改善的代码（重复、过长方法、不恰当命名、过大的类）；第三步，应用一个小的重构手法（如提取方法）；第四步，立即运行所有测试验证没有破坏任何东西；第五步，如果测试通过，提交这次小的重构或继续下一个重构；如果测试失败，撤销这次改动（Git stash或IDE的撤销功能），重新分析问题。关键原则是"一次只做一个变化"——一次重构多个方面会让调试变得困难。Martin Fowler建议每次重构后运行测试的时间不应超过10秒。

常用重构手法

以下是TDD实践中最高频的重构手法：提取方法（Extract Method）——将一个代码块抽取为独立方法，并赋予描述性名称，是使用最频繁的重构手法；内联方法（Inline Method）——当方法体比方法名更清晰时，将方法内容内联到调用处；移动方法（Move Method）——将方法移动到更合适的类中，降低耦合；重命名（Rename）——为变量、方法、类赋予更能表达意图的名称。这些手法的共同特点是每一步都很小、可逆、且能通过测试安全验证。

重构实例：提取方法与参数化

# 重构前 — 重复的条件判断逻辑
def calculate_discount(order):
    if order.total > 1000 and order.is_vip:
        return order.total * 0.8
    elif order.total > 500:
        return order.total * 0.9
    elif order.total > 200:
        return order.total * 0.95
    return order.total

# 重构第1步 — 提取折扣率计算为独立方法
def calculate_discount(order):
    return order.total * _get_discount_rate(order)

def _get_discount_rate(order):
    if order.total > 1000 and order.is_vip:
        return 0.8
    elif order.total > 500:
        return 0.9
    elif order.total > 200:
        return 0.95
    return 1.0

# 重构第2步 — 进一步用策略模式替代条件分支
from dataclasses import dataclass

@dataclass
class DiscountTier:
    min_total: float
    rate: float
    requires_vip: bool = False

class DiscountCalculator:
    TIERS = [
        DiscountTier(1000, 0.8, requires_vip=True),
        DiscountTier(500, 0.9),
        DiscountTier(200, 0.95),
        DiscountTier(0, 1.0),
    ]

    def get_rate(self, order):
        for tier in self.TIERS:
            if order.total >= tier.min_total:
                if tier.requires_vip and not order.is_vip:
                    continue
                return tier.rate
        return 1.0

def calculate_discount(order):
    calculator = DiscountCalculator()
    return order.total * calculator.get_rate(order)

以上重构过程清晰地展示了"小步快跑"的精髓：每一步都保持测试通过，每一步都在改善代码结构。从条件分支到策略模式，代码的可扩展性和可测试性都得到了显著提升，而这一切都是在测试安全网的保障下完成的。

重构与测试保障

高质量的重构依赖于高质量的测试覆盖。一个常见的误区是认为"有测试就行了"，但测试的质量同样重要。好的测试应当是行为测试而非实现测试——它测试"做什么"而非"怎么做"。如果测试与实现细节耦合太紧（例如测试了私有方法、验证了内部状态），那么重构时测试会大面积失败，导致安全网失效。这也是为什么TDD强调"测试行为而非实现"的原因——好的测试为你重构的自由，坏的测试让你束手束脚。一个实用的检测方法是：如果在重构过程中你需要修改测试代码，说明测试与实现耦合太紧。

八、TDD在遗留代码

遗留代码（Legacy Code）通常指没有测试的代码。Michael Feathers在其著作《Working Effectively with Legacy Code》中给出了一个简洁而深刻的定义："遗留代码就是没有测试的代码。"对于这类代码库，直接应用TDD是不可行的——因为你无法先写一个会失败的测试：代码已经存在，而且很可能不可测试。处理遗留代码的策略不是"直接TDD"，而是一套循序渐进的"将代码置于测试之下"的技术。

接缝（Seam）识别

接缝（Seam）是Michael Feathers提出的核心概念——它指的是程序中那些可以在不修改代码本身的情况下改变行为的位置。在Python中，接缝主要包括：函数参数（可以传入不同的参数）、类继承（可以继承并重写方法）、模块导入（可以Mock整个模块）、环境变量（可以通过设置环境改变行为）、条件编译（虽然Python没有预处理器，但可以通过条件判断实现类似效果）。识别接缝是将遗留代码置于测试之下的第一步——只有找到可以"插入"测试代码的位置，才能编写测试。

# 遗留代码：一个没有接缝的硬编码函数
def send_report():
    import smtplib
    server = smtplib.SMTP("smtp.company.com")
    server.login("bot@company.com", "password123")
    server.sendmail("bot@company.com", ["admin@company.com"],
                    "Report: all systems OK")
    server.quit()

# 通过添加参数创建接缝（不改变原有行为）
def send_report(smtp_host="smtp.company.com", user="bot@company.com",
                password="password123", recipient="admin@company.com"):
    import smtplib
    server = smtplib.SMTP(smtp_host)
    server.login(user, password)
    server.sendmail(user, [recipient], "Report: all systems OK")
    server.quit()

# 现在可以注入Mock测试
def test_send_report():
    with patch("smtplib.SMTP") as mock_smtp:
        send_report(smtp_host="mock", user="x", password="y", recipient="test@test.com")
        mock_smtp.return_value.sendmail.assert_called_once()

Characterization测试

Characterization测试（特征测试）是处理遗留代码的关键技术。它的思路是：不理解代码的具体逻辑，而是运行代码并记录它的实际行为，然后将这个行为"固化"为测试。即使代码的行为"看起来有bug"，也先把当前行为记录下来——因为改变已有行为可能造成意想不到的后果。具体步骤为：第一步，在代码周围编写测试脚手架（调用目标函数，传入典型参数）；第二步，运行代码并捕获输出、返回值、异常、副作用；第三步，将捕获的结果写成断言——"这段代码在给定输入X时，输出Y"；第四步，运行这些测试确认它们能捕获代码的当前行为。

# 遗留函数 —— 我们不理解它在做什么，但需要覆盖它
def mystery_transform(data):
    result = []
    for i, x in enumerate(data):
        if i % 2 == 0:
            result.append(x * 2)
        else:
            result.append(x + 1)
    return result

# Characterization测试 —— 记录当前行为
def test_mystery_transform_characterization():
    # 通过实际运行来发现行为
    result = mystery_transform([1, 2, 3, 4, 5])

    # 将观察到的行为固化为测试
    assert result == [2, 3, 6, 5, 10]
    # 索引0(偶数): 1*2 = 2
    # 索引1(奇数): 2+1 = 3
    # 索引2(偶数): 3*2 = 6
    # 索引3(奇数): 4+1 = 5
    # 索引4(偶数): 5*2 = 10

逐步覆盖与安全重构

对遗留代码做TDD的正确策略是"三步循环"：第一步，找到一小块需要改动或理解的代码区域，通过接缝技术将其置于测试之下（使用Characterization测试或手动编写测试）；第二步，在测试的保护下安全地重构代码——改善命名、提取方法、消除重复，直到代码变得清晰可维护；第三步，现在代码已经具备了可测试性，可以对新的功能需求应用标准的TDD流程。这个循环每次只处理一小块区域，逐步扩大测试覆盖范围。

# 遗留代码逐步覆盖策略示意 class LegacyPaymentProcessor: # 一个2000行的类，没有测试，不可测试 def process(self, data): # ... 2000行 spaghetti 代码 ... pass # 第1步：在调用点创建接缝 def process_payment(processor_class=LegacyPaymentProcessor): proc = processor_class() # ... 调用逻辑 ... # 第2步：编写Characterization测试 def test_legacy_processor_characterization(): # Mock外部依赖，记录当前行为 with patch.object(LegacyPaymentProcessor, "connect_db"): with patch.object(LegacyPaymentProcessor, "send_email"): result = process_payment() # 断言当前行为 assert result is not None # 第3步：重构——提取小方法（在测试保护下） # 每次提取一个小方法，运行测试确认不破坏行为 # 多次迭代后，代码变得可测试，新功能可以TDD

处理遗留代码需要极大的耐心。Michael Feathers建议每次提交改动不要超过"在版本控制中能清晰看出变化"的粒度。对于完全没有测试的遗留系统，目标是"不要让情况变得更糟，每次接触代码都留下一小块测试覆盖"。经过持续努力，遗留代码库最终会被测试网络所覆盖，届时就可以全面应用TDD了。

九、TDD最佳实践

经过数十年的TDD实践与演进，社区积累了一系列行之有效的最佳实践。这些实践不是教条，而是从大量成功和失败案例中提炼出的原则。遵循它们可以显著提高TDD的生产力和可持续性。

FIRST原则

FIRST是衡量单元测试质量的五个维度的首字母缩写：快速（Fast）——测试应该运行得很快，一个完整的测试套件应该在几分钟内运行完毕。如果测试很慢，开发者就不会频繁运行它，从而失去TDD的快速反馈优势。隔离（Isolated）——每个测试应该独立于其他测试运行，测试之间不应该共享状态或依赖执行顺序。可重复（Repeatable）——测试在任何环境下都应该产生相同的结果，不应该依赖不可控的外部因素（如网络、时间）。自验证（Self-validating）——测试应该输出布尔结果（通过/失败），不需要人工检查日志或输出来判断。及时（Timely）——测试应该在生产代码之前编写（这正是TDD的核心要求）。

测试命名规范

好的测试命名是测试即文档的基础。推荐的命名模式是 `test_<被测试方法>_<场景>_<期望行为>`。这个三部分模式涵盖了被测试的单元、测试的条件上下文、以及预期的结果。例如 `test_deposit_with_negative_amount_raises_error` 清晰地表达了：测试deposit方法、在负数金额场景下、期望抛出错误。好的测试名称应该能替代注释，让阅读者在不看测试体的情况下就能理解测试意图。

# 好的测试命名 —— 自我文档化
def test_withdraw_insufficient_balance_raises_error():
    """取款金额超过余额时应该抛出异常。"""
    account = BankAccount(balance=100)
    with pytest.raises(InsufficientBalanceError):
        account.withdraw(200)

def test_withdraw_sufficient_balance_reduces_balance():
    """取款金额不超过余额时应该减少余额。"""
    account = BankAccount(balance=100)
    account.withdraw(60)
    assert account.balance == 40

One Assert per Test

"每个测试一个断言"原则由Dave Astels和Roy Osherove倡导。其核心理念是：一个测试应该只验证一个行为逻辑。如果测试中有多个断言，且第一个失败了，后续的断言不会执行，你就失去了了解全部失败信息的机会。更重要的是，多断言测试往往在测试多个不同的行为——这意味着它应该被拆分为多个测试。当然，这个原则有合理的例外：当多个断言共同验证一个逻辑概念时（例如验证一个对象的多个属性），它们是合理的。关键判断标准是：如果这些断言中任何一个失败，你能立即知道是哪个行为被破坏了。如果答案是"需要看断言行号才知道"，那就说明应该拆分。

# 应该被拆分的测试 —— 测试了多个行为
def test_user_creation():
    user = create_user("alice@example.com", "pass123")
    assert user.email == "alice@example.com"
    assert user.is_active == True
    assert user.role == "member"
    # 如果第二个断言失败，你不知道邮箱、激活状态还是角色出了问题

# 拆分后的测试 —— 每个测试一个逻辑断言
def test_user_creation_sets_email():
    user = create_user("alice@example.com", "pass123")
    assert user.email == "alice@example.com"

def test_new_user_is_active_by_default():
    user = create_user("alice@example.com", "pass123")
    assert user.is_active == True

def test_new_user_has_member_role():
    user = create_user("alice@example.com", "pass123")
    assert user.role == "member"

保持测试速度

测试速度直接决定了TDD的可持续性。如果测试套件需要10分钟才能运行，开发者一天只能跑几次，TDD的快速反馈优势就荡然无存。维持测试速度的策略包括：严格区分单元测试（纯内存、无I/O）和集成测试（涉及数据库、网络），在开发过程中只跑单元测试，持续集成中再跑全部测试；对慢测试使用标记（pytest的mark）来分类，方便选择性执行；使用测试固件（fixture）的重用来减少重复设置开销；对大对象使用工厂函数而非每次都从头创建。

# 使用pytest.mark区分测试速度等级
import pytest

@pytest.mark.fast
def test_core_business_logic():
    """核心业务逻辑 —— 纯内存，毫秒级。"""
    result = calculate_discount(order_total=1000, is_vip=True)
    assert result == 800

@pytest.mark.slow
def test_database_integration():
    """数据库集成测试 —— 需要真实数据库，秒级。"""
    user = User.objects.create(email="test@test.com")
    assert user.id is not None

# 开发时只跑快速测试
# $ pytest -m fast

# CI中跑所有测试
# $ pytest

TDD实践检查清单

在日常TDD实践中，可以参考以下检查清单来确保自己走在正确的轨道上：我是否先写了一个失败的测试？测试是否只描述了一个行为？我是否写了刚好能通过测试的最少代码？我的测试是否不依赖于其他测试的执行结果？我的测试命名是否清晰地表达了场景和期望？我的测试运行速度是否足够快？在重构阶段我是否保持了测试全部通过？我是否避免了在测试中访问私有成员？我是否没有对值对象做Mock？我的测试是否可以在任何顺序下通过？

最后需要强调的是，TDD不是银弹。它最适合逻辑密集型的业务代码，对于UI、并发、探索性开发等场景需要调整策略。但是，即使在不严格应用TDD的项目中，"先想清楚行为再写代码"这个核心思想依然具有普遍价值。TDD最终教会我们的不是如何写测试，而是如何以可控、可预测、可重复的方式构建软件。

核心要点总结：

TDD的核心是"红-绿-重构"三拍子循环，每个循环产生一个经过验证的代码增量。

测试先行驱动出更好的接口设计——因为你在写测试时就是在从调用者角度审视API。

Kata刻意练习是内化TDD节奏的最有效方式，建议每个Kata重复3-5遍。

Mock应适度使用——隔离外部依赖，但不要Mock值对象和简单数据结构。

Web TDD需要分层策略：单元测试聚焦业务逻辑，集成测试验证真实交互。

遗留代码的TDD从找接缝（Seam）开始，用Characterization测试记录当前行为，逐步扩展覆盖。

FIRST原则（快速、隔离、可重复、自验证、及时）是衡量测试质量的金标准。

好的测试命名 = 被测试方法 + 场景 + 期望行为，三者构成测试即文档。