Python测试驱动开发教程_TDD方法与pytest实战解析

TDD是测试驱动开发，严格遵循“红—绿—重构”循环：先写失败测试、再写最简通过代码、最后在测试保护下优化结构；测试是设计文档和验收标准，而非事后验证。

什么是TDD，它和普通写测试有什么不同

TDD（Test-Driven Development）不是“先写代码再补测试”，而是严格遵循“红—绿—重构”三步循环：先写一个**失败的测试**（红），再写**刚好能让测试通过的最简代码**（绿），最后在测试保护下**优化代码结构**（重构）。关键在于测试是功能的**设计文档和验收标准**，而不是事后验证工具。比如你要实现一个add(a, b)函数，第一步不是写函数，而是写assert add(2, 3) == 5——此时函数还不存在，测试必然失败。

用pytest快速启动TDD流程

pytest天然适合TDD：语法简洁、断言直观、支持参数化、无需继承类。安装后直接创建test_calculator.py，从一个失败测试开始：

• 写测试：def test_add_returns_sum(): assert add(1, 2) == 3
• 运行pytest test_calculator.py -v，看到红色报错（NameError: name 'add' is not defined）
• 在同目录建calculator.py，只写def add(a, b): return a + b
• 再次运行测试，变成绿色 ✔️
• 接着写下一个测试，比如test_add_handles_negative_numbers，重复循环

让TDD真正落地的三个实操要点

新手常卡在“不知道测什么”或“改着改着测试崩了”。记住这三点：

• 每次只驱动一个微小行为：不要一上来测“用户登录全流程”，而是从“空密码返回错误提示”开始
• 测试名必须描述意图，不是技术动作：用test_deposit_increases_balance，别用test_test_deposit
• 重构阶段要敢删代码：当新增测试迫使你重复写if判断，就该提取函数；当两个测试共享setup逻辑，就该用@pytest.fixture

避免TDD半途而废的常见陷阱

很多人坚持几轮就放弃，往往因为：

立即学习“Python免费学习笔记（深入）”；

• 测试太慢：用内存对象替代数据库/HTTP调用，pytest-mock打桩外部依赖
• 测试太脆：不校验具体异常消息，只断言with pytest.raises(ValueError)；不用datetime.now()，改用可注入的时钟对象
• 把TDD当成KPI：不必100%覆盖率才提交，重点是核心路径有测试护航，边界情况逐步覆盖

TDD不是给代码上锁，而是给思考装上刹车——每一步都问：我到底想让程序做什么？