unittest中requests断言失败主因是响应类型不匹配（如字符串vs数字）、编码乱码或JSON解析异常；应优先用response.json()、避免硬索引、复用Session并集中管理配置。
requests发请求后，unittest里断言响应失败？
常见现象是 assertEqual 报错，比如期望 {"code": 0} 却拿到 {"code":"0"}（字符串 vs 数字），或响应体是 bytes 但直接拿 str 比较。requests 默认返回 response.text 是 str，但若接口返回非 UTF-8 编码（如 GBK），response.text 可能乱码，导致断言永远不通过。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 优先用
response.json()解析响应，它自动处理编码并转成 Python 字典，比手动json.loads(response.text)更可靠 - 如果接口不返回合法 JSON（比如纯文本或空响应），先检查
response.status_code == 200，再判断response.content长度，避免json.JSONDecodeError - 断言字段值时，用
self.assertEqual(resp_json.get("code"), 0)而不是硬写resp_json["code"]，防止 KeyError 中断测试
unittest中如何复用requests会话（Session）？
每次测试都新建 requests 实例，无法携带 Cookie、无法复用 TCP 连接，既不符合真实用户行为，也拖慢测试速度。直接在 setUp 里写 self.session = requests.Session() 看似可行，但要注意：Session 不会自动管理登录态生命周期，如果测试用例之间有依赖（比如先登录再操作），必须显式控制顺序或重置状态。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 在
setUpClass中创建cls.session = requests.Session()，并在tearDownClass中调用cls.session.close() - 登录接口返回的 token 或 set-cookie，用
cls.session.headers.update({"Authorization": "Bearer xxx"})或让 requests 自动处理 Cookie（默认开启） - 避免在单个测试方法里多次调用
cls.session.post(..., json=...)后又忘记清空 headers，否则后续请求可能带上不该带的头
测试数据写死在代码里，一改接口就全挂？
把 URL、参数、预期结果全写成字符串常量，表面看着清楚，实际维护成本极高。比如环境从 http://test.api.com 切到 http://staging.api.com，得全局搜索替换；又或者某字段名从 user_id 改成 uid，十几个用例同时报错。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用模块级变量集中管理基础配置：
BASE_URL = os.getenv("API_BASE_URL", "https://test.api.com") - 测试参数用字典定义，不要拼接字符串：
valid_payload = {"username": "test", "password": "123"} - 预期响应结构用最小必要字段断言，例如只验
"code"和"data"是否存在，不校验data里每个子字段——那是接口契约的事，不是单测该管的
运行 unittest 时 requests 报 ConnectionRefusedError？
错误信息通常是 ConnectionRefusedError: [Errno 111] Connection refused，说明 requests 尝试连接的目标地址根本没服务在跑，或者端口不对。这不是代码逻辑问题，而是环境没对齐。比如本地跑测试却指向了公司内网域名，或 Docker 容器网络未打通。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 在测试类开头加快速连通性检查：
try: requests.get(f"{BASE_URL}/health", timeout=2)，失败则self.skipTest("API server unreachable") - 确保
BASE_URL不含末尾斜杠（https://api.com/），否则拼接路径时变成https://api.com//login，有些网关会 404 - CI 环境中禁用代理：设置环境变量
NO_PROXY="*"或在 Session 上显式关闭：session.trust_env = False
真正麻烦的从来不是发请求或写断言，而是让每一次请求都落在正确的环境、带着正确的上下文、面对可预测的响应结构。这些细节不显眼，但少做一步，调试时间就翻倍。
