Pytest 不能直接调用 Web 控制器函数进行单元测试，因其严重依赖框架上下文（如 request、session、依赖注入等），裸调用会因缺失上下文而抛出 RuntimeError 或解析失败；必须通过框架测试客户端（如 Flask test_client 或 FastAPI TestClient）模拟真实 HTTP 请求来验证接口契约。
Pytest 本身不直接测试 Web 控制器层，必须配合框架的测试客户端（如 Flask 的 test_client 或 FastAPI 的 TestClient）才能模拟 HTTP 请求并验证控制器行为。
为什么不能直接对控制器函数调用做单元测试？
Web 控制器（比如 Flask 中的路由函数、FastAPI 中的 @app.get 装饰函数）通常依赖框架注入的上下文对象：request、current_user、session、查询参数解析、请求体自动反序列化等。裸调用函数会缺失这些，导致 RuntimeError（如 “Working outside of application context”）或参数解析失败。
实操建议：
- 始终通过框架提供的测试客户端发起请求，而非直接调用视图函数
- 用
pytest.fixture封装测试客户端初始化逻辑，避免每个测试重复写app.test_client() - 对 FastAPI，优先用
TestClient（来自fastapi.testclient），它兼容 ASGI 生命周期，能正确处理依赖注入
如何模拟认证和请求头？
控制器常校验 Authorization 头或 session 状态。直接传空头会导致 401/403，但硬编码真实 token 又让测试脆弱。
立即学习“Python免费学习笔记（深入）”；
实操建议：
- 用
headers={"Authorization": "Bearer test-token"}手动构造头，配合测试用的简易 JWT 验证逻辑（如 FastAPI 的Depends替换为返回固定用户） - 在 fixture 中 patch 认证依赖：例如用
monkeypatch.setattr替换get_current_user为返回MockUser(id=1) - 避免在测试中启动真实 Redis 或数据库来验证 session；用内存字典 mock
session_store
如何测试 JSON 请求体和表单数据？
不同 Content-Type 触发不同解析路径：application/json 走 JSON 解析，application/x-www-form-urlencoded 走 form 解析。错配会导致 422 Unprocessable Entity（FastAPI）或 400 Bad Request（Flask）。
实操建议：
- POST JSON 时，用
client.post("/api/users", json={"name": "alice"})——json=参数会自动设头、序列化、发送 - POST 表单时，用
client.post("/login", data={"username": "a", "password": "b"})——data=对应application/x-www-form-urlencoded - 不要混用：
json=和headers={"Content-Type": "application/x-www-form-urlencoded"}会导致解析失败 - 验证响应时，优先检查
response.status_code == 201和response.json()["id"]，而非只看状态码
测试数据库交互时的关键取舍
控制器层测试若连真实数据库，会变慢、不可靠、难并行。但完全 mock ORM 层（如 patch session.add）又可能掩盖 SQL 错误或事务边界问题。
实操建议：
- 用 SQLite 内存数据库（
sqlite:///:memory:）替代 PostgreSQL/MySQL，速度快且隔离性好 - 在每个测试前用
Base.metadata.create_all(engine)建表，测试后不 drop —— pytest 的scope="function"fixture 可保证干净状态 - 避免在测试里写
assert user.name == "test"后再查库验证；应直接 assert 响应体，并信任 ORM 在测试 DB 中已正确落库 - 复杂事务逻辑（如多步更新+异常回滚）才需单独写集成测试，控制器单元测试聚焦“HTTP 接口契约”即可
真正容易被忽略的是：控制器测试不是测业务逻辑，而是测“这个 URL 是否按约定接收输入、返回结构化响应、触发预期副作用（如 DB 写入）”。把校验逻辑、领域规则拆到 service 层单独测试，控制器层就只管胶水逻辑——否则测试会随着接口微调而频繁断裂。
