集成测试前必须确认三件事：目标api服务已启动且网络可达、base_url配置与实际地址完全一致（含末尾斜杠）、测试用例不依赖上一个测试遗留的脏数据。
直接跑通集成测试前必须确认的三件事
集成测试不是写完test_*.py就能跑通的——它依赖真实服务进程、网络可达性、以及数据状态一致性。没确认这三点就开跑，90% 的失败都卡在这儿。
必须手动验证：
- 目标 API 服务已启动，且能被测试机器访问（比如
curl -I http://localhost:8000/health返回 200） -
base_url配置与实际服务地址完全一致（注意末尾斜杠："http://localhost:8000"≠"http://localhost:8000/"） - 测试用例不依赖“上一个测试留下的脏数据”（比如 POST 创建用户后，下一个 GET 不该硬编码 ID，而应从响应中提取或使用固定 fixture 数据）
用 pytest.fixture 管理 API 客户端和测试数据
别在每个测试函数里重复写 requests.get(...) ——封装成 fixture 才能复用、隔离、可测。
推荐写法：
import requests
import pytest
@pytest.fixture
def api_client():
return requests.Session()
@pytest.fixture
def user_payload():
return {"name": "test_user", "email": "test@example.com"}
def test_create_user(api_client, user_payload):
resp = api_client.post("http://localhost:8000/users", json=user_payload)
assert resp.status_code == 201
assert resp.json()["email"] == user_payload["email"]
关键点：
- 用
requests.Session()而非裸requests.get()，便于后续加 headers、auth、重试策略 - 测试数据用 fixture 提供，避免硬编码；敏感字段（如密码）绝不写死在测试代码里
- 不要在 fixture 里做副作用操作（比如自动清库），那会让测试顺序敏感、难以 debug
断言响应时最容易忽略的三个维度
只检查 status_code == 200 是远远不够的。真实集成测试必须覆盖结构、内容、边界。
典型漏判场景：
-
resp.json()报JSONDecodeError：先加assert resp.headers.get("content-type") == "application/json" - 字段存在但类型错：比如返回
"id": "123"（字符串）而非"id": 123（整数），用isinstance(resp.json()["id"], int)显式校验 - 分页接口漏测空列表：
GET /items?page=999应返回200+ 空数组，而非404或500
本地开发时如何绕过真实外部依赖？
集成测试 ≠ 必须连生产环境或第三方 API。用 pytest-mock 或 responses 拦截请求，既保逻辑又避风险。
两种常用方式：
- 对内部调用（如 Flask app 内部发 HTTP 请求到另一个微服务）：用
patch("requests.post")mock 返回值 - 对外部服务（如 Stripe、Auth0）：用
responses.add(responses.GET, "https://api.stripe.com/v1/...", json={...})注册模拟响应 - 注意：mock 只适用于单元/组件测试；真正的集成测试仍需连接真实后端，二者不可互相替代
真正麻烦的从来不是写断言，而是让测试在 CI 和本地表现一致——比如数据库初始状态、服务启动顺序、超时阈值。这些细节不提前对齐，测试就会变成“看运气运行”。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
