因为setUpTestData共享数据易致脏状态，而Factory Boy每次生成全新实例并自动处理外键等关联关系，天然隔离且更可靠。
为什么不用 TestCase.setUpTestData 而要选 Factory Boy
因为 setUpTestData 只能创建一次数据供整个测试类共享，一旦某个测试修改了对象状态（比如调用 save() 或改字段），其他测试会看到脏数据；而 Factory Boy 每次调用都生成全新实例，天然隔离。更关键的是：它自动处理外键、OneToOneField 和 _set 反向关系——比如你写 user = factory.SubFactory(UserFactory)，它不会报错或静默跳过，而是真建一个 User 并关联。
常见错误是工厂类没继承 factory.django.DjangoModelFactory，或者字段名和模型不一致（如把 profile_set 写成 profiles），结果外键没被创建，测试跑通但逻辑实际没走通。
-
UserFactory必须定义username = factory.Sequence(lambda n: f"user_{n}")，否则多测试并行时因唯一约束报错 - 密码字段必须用
password = factory.PostGenerationMethodCall("set_password", "test123")，否则authenticate()会返回None - 不要在工厂里手动调用
save()或full_clean()——DjangoModelFactory已内置这些逻辑
pytest-mock 打补丁打在哪？看调用方，不是定义方
这是最常踩的坑：想 mock 一个常量或函数，却 patch 了它被定义的地方，而不是被使用的地方。比如模块 utils.py 里写了 from myapp.conf import API_TIMEOUT，然后在函数里直接用 API_TIMEOUT；你在测试里写 mocker.patch("myapp.conf.API_TIMEOUT") 是无效的 —— 因为 utils.py 在导入时已经把值拷贝进自己命名空间了。
正确做法是 patch utils.py 模块里的名字：mocker.patch("myapp.utils.API_TIMEOUT")。同理，如果 view 里写了 from django.contrib.auth import get_user_model，你要 mock 的是 "myapp.views.get_user_model"，不是 "django.contrib.auth.get_user_model"。
- 补丁目标永远是「被测代码实际访问的路径」，不是源码路径
- 用
mocker.patch.object替代字符串路径更安全，比如mocker.patch.object(myapp.views, "get_user_model") - 对 Celery task 的 mock，必须 patch 导入它的模块，例如 view 中
from myapp.tasks import send_email，就 patch"myapp.views.send_email"
数据库操作测试该用 TestCase 还是 TransactionTestCase
95% 的场景用 django.test.TestCase 就够了 —— 它把每个测试包在事务里，速度快、隔离性好。只有当你明确需要测试 commit 后的行为（比如信号触发、数据库触发器、或真实事务边界），才升级到 TransactionTestCase。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
但注意：TransactionTestCase 会清空整个数据库再重建 schema，比 TestCase 慢 10 倍以上。如果你只是想测带 select_for_update() 的逻辑，其实可以用 TestCase + atomic() 手动包裹，避免降级。
-
TestCase不支持LiveServerTestCase那种跨请求事务，别混用 - 测试中调用
connection.cursor()执行原生 SQL 时，TestCase仍有效，只要不显式commit - 若用内存 SQLite（
NAME=":memory:"），TransactionTestCase无法工作，会报DatabaseError: no such table
如何让测试既快又覆盖真实路径
快的关键是切断外部依赖，但切太多会导致“测试通过、线上挂掉”。真实路径 ≠ 全链路调用，而是指“关键分支是否被触发”。比如测试一个发邮件的 view，你不需要真连 SMTP，但得验证 send_mail() 是否被以正确参数调用；这时用 mocker.patch("django.core.mail.send_mail")，然后检查 mock_send_mail.assert_called_once_with("Hi", "body", ..., ["user@example.com"])。
另一个容易忽略的点：时间敏感逻辑。比如一个判断“是否超时”的方法依赖 timezone.now()，硬编码时间会导致测试脆弱。应统一用 freezegun 或 mocker.patch("django.utils.timezone.now") 控制时间戳，而不是在测试里算秒数差。
- 避免 patch 太深的路径，比如
"requests.adapters.HTTPAdapter.send"—— 改用responses库 mock HTTP 层更稳定 - 对 Django 表单验证的测试，直接传
data={...}给MyForm(data=...)即可，不用构造 request - 测试中间件或装饰器行为，优先写独立函数测试其逻辑，而不是起完整请求 —— 后者慢且难 debug
测试真正难的不是写断言，而是判断哪些路径必须走真实 DB、哪些必须 mock、哪些可以跳过。比如外键约束错误、唯一索引冲突、事务回滚后状态，这些不模拟就测不出来；而第三方 API 返回值、邮件发送成功与否，mock 更可靠。边界在哪里，得看失败时你最想快速定位到哪一层。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
