TDD 实战：如何用测试驱动编写更优的 Python 代码

TDD 实战：如何用测试驱动编写更优的 Python 代码

'先写测试，再写代码。'第一次听到这句话时，我以为这是某种程序员的玄学。直到我在一个真实项目中被 bug 折磨了三天，才终于决定认真对待它。

一、TDD 是什么？为什么它能改变你的编码方式？

测试驱动开发（Test-Driven Development，TDD）并不是一种测试技术，而是一种设计哲学。

它的核心节奏只有三个步骤，被称为'红绿重构循环'：

🔴 Red → 写一个会失败的测试
🟢 Green → 写最少的代码让测试通过
🔵 Refactor → 在测试保护下重构代码

听起来简单，但真正实践后你会发现，这个节奏从根本上改变了你思考问题的顺序——你不再先想'怎么实现'，而是先想'这个函数应该如何被使用'。这个微小的视角转变，会让你写出接口更清晰、耦合更低、更容易维护的代码。

二、一个真实案例：电商优惠券计算系统

让我用一个我真实经历过的项目来展示 TDD 的完整节奏。

背景

某电商平台需要实现一套优惠券计算逻辑，规则如下：

• 满 100 减 10，满 200 减 30，满 500 减 80
• VIP 用户在此基础上额外享受 9.5 折
• 优惠叠加后价格不得低于原价的 6 折
• 无效优惠券直接抛出异常

在没有 TDD 之前，我会直接开始写 CouponCalculator 类，写完后再手动测几个数字看看对不对。这种方式导致的问题是：边界条件经常遗漏，改一个规则可能悄悄破坏另一个规则，上线后才发现 bug。

下面我们用 TDD 重新来过。

第一轮红绿重构：基础满减逻辑

🔴 Step 1：先写测试（此时代码还不存在）

# test_coupon.py
import pytest
from coupon import CouponCalculator

class TestCouponCalculator:
    def setup_method(self):
        self.calc = CouponCalculator()

    def test_no_discount_below_100(self):
        """不满 100 元，不打折"""
        assert self.calc.apply(99.0) == 99.0

    def test_discount_100(self):
        """满 100 减 10"""
        assert self.calc.apply(100.0) == 90.0

    def test_discount_200(self):
        """满 200 减 30"""
        assert self.calc.apply(200.0) == 170.0

    def test_discount_500(self):
        """满 500 减 80"""
        assert self.calc.apply(500.0) == 420.0

运行测试：

$ pytest test_coupon.py
ERROR: ModuleNotFoundError: No module named 'coupon'

红灯亮起。 完美，这正是我们期待的结果。

🟢 Step 2：写最少的代码让测试通过

# coupon.py
class CouponCalculator:
    # 满减规则：按金额从大到小排列，优先匹配高档位
    RULES = [(500, 80), (200, 30), (100, 10)]

    def apply(self, price: float) -> float:
        for threshold, discount in self.RULES:
            if price >= threshold:
                return price - discount
        return price

$ pytest test_coupon.py
....[100%] 4 passed in 0.05s

绿灯。 注意：这里我没有过度设计，只写了让测试通过的最简实现。

🔵 Step 3：重构

代码已经足够简洁，暂时不需要重构。进入下一轮。

第二轮红绿重构：VIP 折扣

🔴 先写测试

def test_vip_extra_discount(self):
    """VIP 在满减基础上额外 95 折"""
    # 满 100 减 10 后剩 90，再打 95 折
    assert self.calc.apply(100.0, is_vip=True) == pytest.approx(85.5)

def test_non_vip_no_extra_discount(self):
    """非 VIP 不享受额外折扣"""
    assert self.calc.apply(100.0, is_vip=False) == 90.0

$ pytest test_coupon.py
FAILED: TypeError: apply() got an unexpected keyword argument 'is_vip'

🟢 修改代码

class CouponCalculator:
    RULES = [(500, 80), (200, 30), (100, 10)]
    VIP_DISCOUNT = 0.95

    def __init__(self, min_ratio=0.6):
        self.min_ratio = min_ratio

    def apply(self, price: float, is_vip: bool = False) -> float:
        original_price = price
        # 满减计算
        for threshold, discount in self.RULES:
            if price >= threshold:
                price = price - discount
                break
        # VIP 额外折扣
        if is_vip:
            price = price * self.VIP_DISCOUNT
        # 最低价保护
        min_price = original_price * self.min_ratio
        price = max(price, min_price)
        return round(price, 2)

第三轮红绿重构：最低价格保护

这是最容易被遗漏的边界条件，但在 TDD 中，我们先写测试，就是在强迫自己思考这些边缘情况。

🔴 先写测试

def test_min_price_protection(self):
    """优惠后价格不得低于原价 6 折"""
    # 原价 500，最低不能低于 300
    # 满 500 减 80=420，VIP 打 95 折=399，高于 300，正常
    pass

def test_min_price_protection_triggered(self):
    """模拟极端情况：假设规则叠加后低于 6 折下限"""
    # 我们手动构造一个边界场景来验证保护机制
    calc = CouponCalculator(min_ratio=0.9)  # 最低 9 折
    # 原价 100，满减 10=90，打 95 折=85.5，低于 90
    assert calc.apply(100.0, is_vip=True) == pytest.approx(90.0)

def test_invalid_price_raises_error(self):
    """负数价格应抛出异常"""
    with pytest.raises(ValueError, match="价格不能为负数"):
        self.calc.apply(-10.0)

🟢 完善代码

class CouponCalculator:
    RULES = [(500, 80), (200, 30), (100, 10)]
    VIP_DISCOUNT = 0.95

    def __init__(self, min_ratio=0.6):
        """:param min_ratio: 最终价格不得低于原价的比例，默认 6 折"""
        self.min_ratio = min_ratio

    def _validate(self, price: float) -> None:
        if price < 0:
            raise ValueError("价格不能为负数")

    def _apply_threshold_discount(self, price: float) -> float:
        """满减计算"""
        for threshold, discount in self.RULES:
            if price >= threshold:
                return price - discount
        return price

    def _apply_vip_discount(self, price: float) -> float:
        """VIP 折扣"""
        return price * self.VIP_DISCOUNT

    def _apply_min_price_protection(self, price: float, original: float) -> float:
        """最低价保护"""
        return max(price, original * self.min_ratio)

    def apply(self, price: float, is_vip: bool = False) -> float:
        self._validate(price)
        original_price = price
        price = self._apply_threshold_discount(price)
        if is_vip:
            price = self._apply_vip_discount(price)
        price = self._apply_min_price_protection(price, original_price)
        return round(price, 2)

🔵 重构时机到了

现在代码逻辑清晰了，但 apply 方法职责有点重。趁测试覆盖完整，我们拆分它：

重构完成，再跑一次测试：

$ pytest test_coupon.py -v
test_coupon.py::TestCouponCalculator::test_no_discount_below_100 PASSED
test_coupon.py::TestCouponCalculator::test_discount_100 PASSED
test_coupon.py::TestCouponCalculator::test_discount_200 PASSED
test_coupon.py::TestCouponCalculator::test_discount_500 PASSED
test_coupon.py::TestCouponCalculator::test_vip_extra_discount PASSED
test_coupon.py::TestCouponCalculator::test_non_vip_no_extra_discount PASSED
test_coupon.py::TestCouponCalculator::test_min_price_protection PASSED
test_coupon.py::TestCouponCalculator::test_min_price_protection_triggered PASSED
test_coupon.py::TestCouponCalculator::test_invalid_price_raises_error PASSED
9 passed in 0.08s ✅

全绿。而且现在每个私有方法职责单一，未来需求变更时可以精准修改，不会牵一发动全身。

三、TDD 真正改变了什么？

通过这个案例，你可能已经感受到 TDD 带来的几个深层变化：

1. 你的函数接口设计会更合理

因为你在写代码之前就要'使用'它，自然而然会思考：参数名字是否语义清晰？返回值是否直观？异常是否该抛出？这些问题在先写实现时很容易被跳过。

2. 边界条件不再被遗漏

'负数价格'、'恰好在阈值边界'、'VIP 叠加满减'——这些场景在传统开发中经常等到上线后才暴露。TDD 让你在动手之前就罗列所有场景，测试即文档。

3. 重构变得安全

没有测试的代码重构，就像在没有安全绳的情况下走钢丝。有了完整的测试套件，你可以大胆地拆分方法、重命名变量、调整结构，只要绿灯亮着，你就知道自己没有破坏任何东西。

4. 调试时间大幅减少

这是我个人体会最深的一点。引入 TDD 之后，我在 Python 项目中用于调试的时间减少了大约 60%。原因很简单：大多数 bug 在测试阶段就被截获了，而不是在集成测试或生产环境中才现身。

四、在 Python 项目中落地 TDD 的实用建议

工具选择

pip install pytest pytest-cov

pytest 是 Python 生态中最主流的测试框架，语法简洁，插件丰富。pytest-cov 用于生成代码覆盖率报告：

pytest --cov=coupon --cov-report=term-missing

测试文件组织

project/
├── src/
│   └── coupon.py
├── tests/
│   ├── __init__.py
│   └── test_coupon.py
└── pytest.ini

pytest.ini 基础配置

[pytest]
testpaths = tests
test_*

一个容易忽视的技巧：参数化测试

当你有大量相似的测试用例时，用 @pytest.mark.parametrize 避免重复：

@pytest.mark.parametrize("price,expected", [
    (50, 50.0),
    (100, 90.0),
    (200, 170.0),
    (500, 420.0),
    (600, 520.0),
])
def test_threshold_discounts(self, price, expected):
    assert self.calc.apply(price) == expected

这比写五个独立的测试函数优雅得多，也更易维护。

五、常见误区与反思

'TDD 会让我写代码变慢'

短期来看，确实会多花 20%~30% 的时间。但中长期来看，减少的调试时间、更低的返工率、更顺畅的需求变更，会让整体交付速度反而更快。这是一种延迟满足的投资。

'每一行代码都要有测试'

不必如此。追求 100% 覆盖率往往适得其反。关注核心业务逻辑、边界条件和容易出错的路径，简单的 getter/setter 不值得为它们写测试。

'先写代码再补测试，效果一样'

效果差异非常大。后补的测试往往是'验证代码做了什么'，而不是'验证需求是否满足'。TDD 的测试是从用户视角出发的，这个顺序本身就是设计过程的一部分。

六、总结

TDD 的节奏——红、绿、重构——表面上是一种测试方法，本质上是一种以终为始的思维方式。它让你在敲下第一行实现代码之前，就把需求、边界和接口想清楚。

在 Python 这门语言中，配合 pytest 的简洁语法和丰富插件，TDD 的实践门槛其实并不高。从今天起，下次开始一个新功能时，不妨先打开测试文件，写下你期望它如何工作，然后再去实现它。

你会发现，红灯亮起的那一刻，不是挫败，而是思考的开始。