红绿重构：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:, 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，再打5
    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
    RULES = [
        (500, 80),
        (200, 30),
        (100, 10),
    ]
    VIP_DISCOUNT = 0.95
    
    def apply(self, price: float, is_vip: bool = False) -> float:
        # 先计:
                price = price - discount
                break
        
        # VIP额外折扣
        if(price, 2)

$ pytest test_coupon.py

......                        

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

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

**🔴 先写测试**

```python
def test_min_price_protection(self):
    """优惠后价格不得低于原价6折"""
    # 原价500，最低不能低于300
    # 满500减80=420，VIP打95折=399，高于300，正常
def test_min_price_protection_triggered(self):
    """模拟极端情况：假设规则叠加后低于6折下限"""
    # 我们手动构造一个边界场景来验证保护机制
    calc = CouponCalculator(min_ratio=0.9)  # 最低9折
    # 原价100，满减10=90，打95折=85.5，低于90（_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
    ):
        """
        :param min_ratio: 最终价格不得低于原价的比例，默认6折
        """
        self.min_ratio = min_ratio
    
    def apply(self, price: float, is_vip: bool = False) -> float:
        if price < 0:
            raise ValueError("价格不能为负数")
        
        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)

🔵 重构时机到了

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

class CouponCalculator:
    
    RULES = [
        (500, 80),
        (200, 30),
        (100, 10),
    ]
    VIP_DISCOUNT = 0.95
    
    def __init__(self, min_ratio.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)

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

$ 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 的实践门槛其实并不高。从今天起，下次开始一个新功能时，不妨先打开测试文件，写下你期望它如何工作，然后再去实现它。

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

---

你在日常开发中是否尝试过 TDD？遇到了哪些阻力或惊喜？欢迎在评论区分享你的经验——那些"踩坑"的故事，往往是最好的技术交流素材。

---

附录：参考资料

• Python 官方文档：docs.python.org
• pytest 官方文档：docs.pytest.org
• 推荐阅读：《测试驱动开发》（Kent Beck）、《Python 测试之道》
• PEP 8 代码风格指南：peps.python.org/pep-0008
• GitHub 推荐项目：pytest-mock、factory_boy、hypothesis（基于属性的测试）