递归函数测试最常漏掉的三个边界是0、1、负值；出错常因边界未处理，如factorial(n)未处理n==0或n
递归函数测试最常漏掉的三个边界：0、1、负值
递归函数出错往往不在主逻辑，而在边界没兜住。比如 factorial(n) 如果没处理 n == 0 或 n ，运行时可能抛 <code>RecursionError 或返回错误结果，但 pytest 默认不会捕获这类崩溃——它会直接 fail 掉整个用例，不输出你期望的断言失败信息。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 每个递归函数必须显式覆盖
n == 0、n == 1、n == -1（或最小合法输入）三类输入，哪怕文档说“只接受正整数”，也要测非法输入是否被拦截 - 用
pytest.raises()明确声明预期异常，例如with pytest.raises(ValueError): factorial(-1) - 避免在测试里依赖全局递归限制，改用
sys.setrecursionlimit()临时调高（仅限深度测试），测完立刻恢复
用 pytest 参数化测试不同递归深度
深度不是越大越好，而是要覆盖临界点：刚好触发 Python 默认递归限制（通常 1000）、比限制小 1、比限制大 1。否则你永远不知道函数在生产环境跑 999 层时是快还是慢，跑 1001 层时是报错还是卡死。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
@pytest.mark.parametrize构造深度序列，例如[1, 5, 999, 1000]，不要只测[1, 10, 100] - 对每个深度，加
timeout保护（需装pytest-timeout插件），如@pytest.mark.timeout(0.1)，防止无限递归拖垮整个测试套件 - 记录实际调用栈深度：在递归函数内用
len(inspect.stack())打印或断言，验证是否真按预期层数展开
mock 递归调用本身来隔离逻辑与深度
当递归逻辑复杂（比如树遍历+状态累积），想单独验证某一层的计算逻辑，又不想跑完整深度时，直接 mock 递归函数自身是最干净的办法。但注意：mock 的是「被调用方」，不是「调用方」；且必须 patch 到被测模块中 import 的位置，不是定义位置。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
patch.object(module, 'func_name', return_value=...)替换递归调用，让第 n 层直接返回预设值，跳过后续递归 - 若需模拟“第 3 层才出错”，可用
side_effect=[val1, val2, Exception('boom')] - mock 后务必检查原函数是否真的没被调用：
mock_func.assert_not_called()或统计调用次数，防止 patch 错 target
性能退化检测：递归 vs 迭代的耗时拐点
递归写起来爽，但 Python 没尾递归优化。当输入规模增大，递归版可能从毫秒级变成秒级，而迭代版仍稳定。这种退化不会导致测试失败，却会在上线后拖垮服务。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 在测试中加入耗时断言：
assert time_taken ，对中等输入（如 <code>n=100）做基线测量 - 用
time.perf_counter()而非time.time()，避免系统时间调整干扰 - 同一台机器上定期重跑性能测试，用
pytest-benchmark存档历史数据，比单纯断言更可靠
递归测试最难的不是写用例，而是判断“这个深度到底算不算合理”——它取决于你的输入分布、部署环境的 sys.getrecursionlimit()、以及 CPython 版本差异。别只信本地开发机的数值。
