http状态码非契约而是实现副产品，仅断言status_code易掩盖逻辑缺陷；setuptestdata数据污染、mock路径错误、迁移验证不全及数据库差异是测试失效主因。
为什么 assertEqual(response.status_code, 200) 会突然让测试挂掉
HTTP 状态码不是契约，而是实现副产品。API 返回 200 可能只是因为中间件吞了异常、或 mock 漏配导致默认成功；而真实错误（如字段校验失败）反而也返回 200 + 错误体。这类断言表面稳定，实则掩盖逻辑缺陷。
- 只校验状态码，不校验响应体结构或关键字段，等于没测业务逻辑
- 依赖具体 HTTP 状态码（比如硬写
401）在权限模型重构后极易失效——新版本可能改用403或统一400带 error_code - 测试运行环境里，开发服务器自动重定向（
302→200）会让status_code断言偶然通过，CI 环境关闭重定向就立刻失败
setUpTestData 和 setUp 混用时数据污染的真实表现
Django 的 setUpTestData 是类级静态初始化，一旦某个测试修改了它创建的实例（比如 user.is_active = False; user.save()），后续所有测试都会拿到脏数据——但报错往往不直接指向这里，而是表现为“某条测试莫名其妙查不到预期对象”。
-
setUpTestData里创建的对象不能被任何测试方法修改，否则污染不可逆；真要改，必须在setUp里重新 create 或用refresh_from_db() - 外键关联对象（如
Profile.objects.create(user=user)）如果在setUpTestData中创建，其外键字段（user）是引用，不是副本——改user就等于改共享对象 - 数据库事务隔离级别低（如 SQLite 默认）时，
setUpTestData创建的数据可能被其他并发测试进程看到，尤其在 CI 使用多 worker 时
用 patch 替换第三方调用时，路径写错一层就白 mock
mock 路径必须和目标代码中 import 和 use 的位置完全一致。常见错误是按“定义位置”去 patch（比如在 utils.py 定义了 send_email，却在测试里 patch myapp.utils.send_email），而实际调用发生在 views.py，且 views.py 是 from utils import send_email ——这时必须 patch myapp.views.send_email。
- 检查方式：在被测函数里加一行
print(send_email)，运行测试看输出的模块路径是什么 - 使用
autospec=True能提前发现签名不匹配（比如原函数要 3 个参数，mock 却只传 2 个），但会拖慢测试速度，本地可开，CI 建议关 - 避免 patch 内置函数（如
datetime.now）到模块顶层；应 patch 到被测模块内实际调用它的位置，否则容易漏掉间接调用路径
测试数据库迁移后，makemigrations --check 不报错但测试仍崩
makemigrations --check 只验证迁移文件能否生成，不验证是否与当前模型定义一致。如果手动编辑过迁移文件（比如删掉一个 RunPython 操作），或模型字段改了但忘记 makemigrations，测试数据库用的是旧 schema，而测试代码按新模型访问字段，就会抛 FieldDoesNotExist 或静默返回 None。
- CI 中务必在测试前执行
python manage.py migrate --fake-initial（仅首次）+python manage.py migrate，而不是依赖create_test_db自动处理 - 在测试基类里加一个
setUpClass方法，用connection.introspection.table_names()和django.apps.apps.get_model()对比字段是否存在，失败时主动报错 - SQLite 测试库默认不校验外键约束，
ForeignKey字段设为null=True但在 PostgreSQL 上实际不允许为空——这种差异要靠多数据库 CI job 暴露，不能只靠本地 SQLite
真正难缠的不是写不写测试，而是当业务逻辑开始绕过表单校验、直连 ORM、或混用 raw SQL 时，那些曾经“稳如老狗”的断言会悄无声息地失去意义。
