tdd的核心价值在于重构安全与设计清晰：改函数逻辑后通过测试快速验证行为不变；需拆分业务规则为独立测试、单断言、参数化覆盖；mock外部依赖避免环境耦合；低覆盖率暴露设计缺陷；ci自动化确认替代人工验证。
测试用例写完才敢改函数逻辑
很多人觉得 TDD 是“先写测试再写代码”的形式主义，其实核心收益在改代码时——你改完 calculate_discount，跑一遍测试就知道有没有意外破坏老行为。没测试的函数，每次加参数、换条件都得手动点一遍 UI 或翻日志，容易漏掉边界分支。
实操建议：
- 把每个业务规则拆成独立测试函数，比如 test_calculate_discount_applies_to_renewal_orders 而不是 test_discount_logic
- 测试里只断言一个行为，失败时能立刻定位是哪条规则崩了
- 用 pytest.mark.parametrize 覆盖不同输入组合，比写一堆重复 assert 更省力也更清晰
mock 外部依赖后，单元测试不依赖数据库或网络
一旦测试要连真实 MySQL 或调 requests.get，速度慢、不稳定、还可能污染数据。TDD 迫使你在设计阶段就把依赖抽象出来，比如把发短信逻辑抽成 NotificationService.send_sms 接口，测试时直接 mock 它。
常见错误现象：
- 测试里出现 os.environ["DB_URL"] 或硬编码 "https://api.example.com"，导致 CI 环境跑不通
- 用 patch mock 错对象（比如 patch "my_module.send_email" 却在 another_module 里调用）
- 忘记检查 mock 是否被调用，导致测试“假通过”（比如断言返回值却没验证是否真发了请求）
覆盖率数字没意义，但缺失的测试暴露设计裂缝
行覆盖率 95% 不代表系统可靠；真正有用的是：某个 if 分支没测试，往往说明这个分支的输入来源模糊、异常处理没想清、或者它本不该存在。
使用场景：
- 新增一个状态字段（如 order.status），发现所有测试都没覆盖 "cancelled" 状态下的价格计算 → 提醒你补全状态机逻辑
- pytest --cov 显示 utils.py 里某个辅助函数完全没被调用 → 是死代码？还是调用路径没走通？值得查
- 有测试但总是跳过（@pytest.mark.skip 或条件判断绕过），基本等于没写
CI 里跑测试比本地快，是因为删掉了“等待人确认”的环节
没有 TDD 的项目，改完代码后常卡在“我是不是改对了？”——要打开浏览器点三遍下单流程，看日志有没有报错，再查数据库字段变没变。TDD 把这部分确认自动化了，CI 一过，就知道集成没问题。
立即学习“Python免费学习笔记（深入）”；
性能与兼容性影响：
- 测试本身要快（单个测试最好 sqlite:///:memory:）代替 PostgreSQL
- 避免在测试里用 time.sleep(0.5) 模拟异步，改用 asyncio.run + unittest.IsolatedAsyncioTestCase
- Python 版本升级时，最先爆出来的往往是测试里用了已弃用的 API（比如 asyncio.async），反而帮你提前踩坑
复杂点在于：测试不是越多越好，而是每个测试都要对应一个可验证的业务意图。写了一堆 assert 对象属性的测试，但没人记得这个属性到底解决什么问题——这种测试半年后就会变成维护负担。
