如何隔离外部依赖做测试：pytest、Fixtures 与 Test Doubles

前置：失败和资源生命周期怎么管：Exception、Context Manager 与 Logging
核心问题：怎样让 Runtime 测试稳定复现外部依赖的行为，同时避免 fixture/test double 自己制造跨用例污染？

状态机 100 个 case 在本地秒级完成，真实 OpenAI/MCP 测试只在集成阶段运行。每个测试拿新的 FakeStateStore；session-scoped mutable store 容易让用例互相污染。

pytest

pytest 是 Python 测试运行框架，负责发现/执行 test、参数化和 assertion reporting；它本身不定义测试数据生命周期或替身行为。

pytest 用于快速 deterministic test、fixture 和 parametrization；Harness 应把真实 provider 分离到明确 integration marker，保证默认测试快且稳定。

pytest fixture 是由测试框架管理的可复用依赖/资源提供机制，具有 function/module/session 等 scope，并负责 setup/teardown；适合数据库、Fake client、临时 workspace 等测试环境。

Fixture 组织可复用测试前置状态，但应控制作用域、避免隐式共享可变对象和巨大 fixture 图。小而明确的 fixture 更易理解。

Fake / Stub / Mock 是不同 Test Double：Stub 返回预置响应，Fake 实现可工作的简化行为，Mock 重点记录并断言交互。选择依据是要验证状态/行为还是调用协议，而不是统一用 Mock。

Runtime 测试通常偏好 Fake/Scripted component，减少对实现细节的脆弱 mock。

症状： 默认测试需要 API key、联网或真实 provider 随机输出。

为什么危险： CI flaky、慢、昂贵。

处理： domain 用 Fake/Scripted；真实 provider/database 放 integration/eval。

Case	断言
单元测试绑定真实网络/模型/数据库	断网运行默认单元测试仍通过。

默认单测一断网就失败。哪些依赖应该换成 Fake/Stub，哪些行为才值得用 Mock 检查交互？
两个测试共享 session-scoped mutable FakeStateStore 后互相污染。把 fixture scope 改成什么，为什么能恢复用例隔离？