回归测试是守住重构边界的哨兵，核心是确保旧行为不被破坏，通过assert覆盖的输入-输出对在重构前后完全一致，需聚焦函数级、快而窄、用mock隔离外部依赖、基于稳定基线建立并随接口演进。

回归测试不是“再跑一遍”，而是守住重构边界的哨兵

重构时没加回归测试，等于在没系安全带的情况下换轮胎——改得越顺手，翻车风险越高。它不保证新逻辑正确，只保证旧行为没被意外破坏。核心判断标准就一条：assert 语句覆盖的输入-输出对，在重构前后必须完全一致。

用 pytest 写回归测试，重点在「快」和「窄」

别写全量端到端测试，那会拖慢每次小修改的反馈速度。回归测试应该聚焦函数级或类级行为，尤其盯住那些容易被重构波及的边界条件。

• 只测公开接口，不测私有方法（_helper 这类）——它们本就不该是契约的一部分
• 每个测试用例只验证一个行为点，比如 calculate_discount(100, "vip") 返回 15.0，而不是塞进五种会员类型一起断言
• 避免依赖外部状态：用 mock 替掉数据库、HTTP 调用，否则测试会不稳定，也掩盖不了逻辑退化
• 把历史 bug 的输入样例直接转成测试用例，比如曾修复过 parse_date("2023-02-30") 抛 ValueError，现在就要保留这个断言

unittest.TestCase 和 pytest 在回归场景下的实际差异

两者都能用，但 pytest 更轻量，更适合回归测试这种“写得快、跑得多”的场景；unittest 的 setup/teardown 模板容易让测试变重，反而让人懒得维护。

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

• pytest 支持参数化（@pytest.mark.parametrize），一行代码就能覆盖多个输入组合，比如 test_calculate_tax 同时喂 0、1000、-50
• unittest 的 self.assertEqual 在报错时只显示值差异，而 pytest 默认展示完整表达式上下文，调试更快
• 如果项目已用 unittest，不必强切，但别为了“统一风格”硬加 setUp——回归测试里多一层初始化，就多一分失效可能

重构前不建基线，等于没做回归测试

很多人重构完才补测试，这已经晚了。真正的回归测试必须基于当前稳定版本的行为快照来建立基线。

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

• 运行一次现有测试套件，确认全部通过，并记录关键输出（如日志片段、返回字典的 json.dumps 结果）作为基线
• 如果原代码没测试，先用 print + 手动验证几个典型输入，把结果存成 baseline.json，再写测试去比对
• 特别注意浮点数、时间戳、随机值等非确定性输出：用 pytest.approx 或截断到毫秒级再比较，否则每次运行都失败
• CI 流水线里，回归测试必须跑在重构分支上，且只比对与主干相同 commit 的基线——跨版本对比毫无意义

最常被忽略的一点：回归测试本身也要随重构演进。函数签名变了，测试里的调用就得同步改；但如果只是内部变量重命名或拆分函数，测试不该动——一旦动了，说明你没守住接口契约。