flaky测试最直接的表现是同一份代码、同一套环境连续运行多次时结果不一致，即有时通过有时失败；关键判断依据是失败不可复现性，需通过多次重跑（如pytest --count=5）验证结果是否波动。
怎么判断一个测试是不是 flaky
flaky 测试最直接的表现是：**同一份代码、同一套环境、连续跑几次，有时通过有时失败**。不是每次必挂，也不是永远绿，而是“看运气”。常见现象包括：AssertionError 随机出现、TimeoutError 偶发触发、KeyError 或 IndexError 在数据结构未初始化完成时抛出。
关键判断依据不是错误类型本身，而是**失败不可复现性**——用 pytest --count=5 --failed-first 重跑单个测试，如果结果不一致（比如 3 次过、2 次挂），基本可定性为 flaky。
- 别只看 CI 日志里一次失败就下结论；必须手动复现多次
- 排除环境干扰：确保没共享状态（如全局变量、临时文件、数据库连接池）
- 注意时间敏感操作：比如
time.sleep(0.1)+threading.Event.wait()组合极易出问题
pytest 中识别 flaky 测试的实用手段
pytest 本身不内置 flaky 检测，但可以用插件或简单脚本辅助定位。最轻量有效的是 pytest-flakefinder：它会自动对每个测试重复运行 N 次，并报告哪些测试结果不稳定。
不用装插件也能快速试：写个 shell 循环跑 pytest test_module.py::test_func -xvs 10 次，配合 grep -c "failed" 看失败次数。比 GUI 工具更可控，也更容易加进本地 pre-commit。
立即学习“Python免费学习笔记（深入）”；
-
pytest-flakefinder的--max-failures=1参数很关键：只要失败一次就停，避免浪费时间 - 慎用
pytest-rerunfailures：它掩盖问题，不是治理手段 - CI 中加
--tb=short和-q，让失败日志紧凑易扫，别被冗余输出带偏注意力
修复 flaky 测试的三个常见下手点
90% 的 Python flaky 测试根子在三类问题：异步等待不充分、共享资源未隔离、时间依赖太强。修复不是靠加 time.sleep，而是让行为确定。
比如用 threading.Event 替代固定延时，用 unittest.mock.patch 拦截外部调用，用 tempfile.TemporaryDirectory 替代硬编码路径。重点不是“让它快点过”，而是“让它每次走同一条路径”。
- 异步逻辑：改用
asyncio.wait_for(task, timeout=...)+ 显式 cancel，而不是裸 await - 数据库/文件：每个测试用独立 schema 或
sqlite:///:memory:，别共用test.db - 随机性：显式传
random.seed(42)，或用pytest.mark.parametrize覆盖边界值，而非依赖random.choice
为什么 mock 不到位会让测试变 flaky
mock 表面看是“让测试快”，实际核心作用是**切断不确定性输入源**。一旦漏 mock 了某个网络请求、系统时钟、或第三方 SDK 内部状态，测试就可能因真实响应延迟、时区差异、或 SDK 版本更新而飘忽。
典型例子：datetime.now() 没被 patch，测试里又用了 assert dt > yesterday —— 在午夜前后跑就可能失败；或者 requests.get 漏了 side_effect，偶尔连上真服务返回 429。
- 检查所有 import 链路：mock 必须打在**测试代码 import 的位置**，不是模块定义的位置
- 用
autospec=True，能提前发现函数签名变化导致的 mock 失效 - 避免在
setup_method里做全局 mock，优先用@patch装饰器或with patch(...):上下文
flaky 测试最难缠的地方不在技术细节，而在“它只在别人机器上出问题”。所以修复后一定要在干净虚拟环境+无缓存模式下验证，别信本地 IDE 里的绿色勾。
