组件级测试需用mock隔离HTTP调用，关键在patch路径与被测代码导入位置一致；SQLite in-memory可替代真实数据库，但须每次新建engine并建表；mock生效须双重校验，禁用autouse避免隐式依赖。
pytest怎么用mock隔离外部HTTP调用
组件级测试的核心是让被测函数只执行自己的逻辑，不真正发请求、不连数据库、不读文件。HTTP调用最常见也最容易“逃逸”，pytest-mock 或原生 unittest.mock.patch 是首选。
关键不是“能不能 mock”，而是 mock 的位置必须和实际导入路径一致——不是函数定义处，而是被测代码里 import 的地方。
- 如果被测模块写了
import requests，就 patch"requests.get" - 如果写了
from utils.api import fetch_user，且fetch_user内部调用了requests.post，那要 patch"utils.api.requests.post"，不是"requests.post" - 用
@patch装饰器时，参数顺序按 patch 顺序从上到下，别把 mock 对象传错位置
示例：某服务类方法 get_profile() 依赖 httpx.AsyncClient，测试时应 patch 类实例的 .get 方法，而不是 patch httpx.AsyncClient 构造函数。
数据库操作怎么替换成内存级桩（SQLite in-memory）
用真实数据库跑测试慢、状态难清理、CI 环境难配。SQLite 的 :memory: 模式是轻量替代方案，但要注意它只对单连接有效；ORM（如 SQLAlchemy）需确保每次测试都新建 engine 和 session。
立即学习“Python免费学习笔记（深入）”；
- 不要复用全局
engine，否则事务隔离失效，测试间互相污染 - 用
pytest.fixture(scope="function")创建新engine，URL 设为"sqlite:///:memory:" - 建表必须在 fixture 中显式调用
Base.metadata.create_all(engine)，因为:memory:每次都是空库 - 若用 Alembic，别在测试中调
upgrade("head")—— 它默认连的是配置里的 DB URL，不是 :memory:，容易静默失败
注意：Django 用户优先用 TestCase 自带的事务回滚机制，比手写 SQLite 桩更可靠。
如何验证 mock 是否真的生效（而不是走通了真实路径）
最常踩的坑是 patch 失败但没报错，测试看似通过，实则调用了真实服务——比如网络未断却误以为 mock 成功。必须做双重校验。
- 在测试末尾加断言：
mock_obj.assert_called_once()，或assert mock_obj.call_count == 1 - 检查调用参数：
mock_obj.assert_called_with(url="https://api.example.com/v1/user", timeout=5) - 主动触发异常路径：设
mock_obj.side_effect = ConnectionError("timeout")，再断言被测函数是否抛出预期错误 - 临时删掉 mock，看测试是否立刻失败（“破坏性验证”）——这是最直接的确认方式
如果 patch 后 assert 仍不触发，大概率是路径写错了，打开被测模块的 __file__，确认 import 语句的模块层级。
fixture 和 autouse=True 的边界在哪
autouse=True 的 fixture 看似省事，但在组件级测试里极易引发隐式依赖和状态残留。
- 数据库 fixture 不要
autouse=True：不同测试可能需要不同初始数据，自动 setup 会掩盖差异 - mock fixture 少用
autouse=True：一个测试 patch 了time.time，下一个测试可能意外继承该 mock，导致时间相关逻辑错乱 - 真正适合 autouse 的只有极少数：比如统一设置
logging.disable(logging.CRITICAL)防止日志干扰输出
组件越小，依赖越明确，越应该显式声明所需 fixture。靠 autouse 掩盖设计模糊，只会让后续维护者更难定位问题源头。
