APIClient比Client更合适是因为它自动处理JSON序列化、Content-Type头、Token认证等，而Client需手动配置；测试权限需用force_authenticate或真实登录；序列化器须先调用is_valid()再查errors；事务相关场景须用TransactionTestCase。
测试DRF视图时，为什么APIClient比Client更合适？
APIClient是DRF提供的专用测试客户端，它自动处理JSON序列化、Content-Type头、认证凭据（如Token）和响应解析，而Django原生的Client默认按HTML表单逻辑处理数据，发POST请求时若不手动设置content_type='application/json'且未json.dumps()数据，会触发415 Unsupported Media Type或静默失败。
-
APIClient调用.post()时，默认将data参数JSON序列化，并设HTTP_CONTENT_TYPE='application/json' - 若需测试Token认证，直接用
client.credentials(HTTP_AUTHORIZATION='Token abc123')，无需手动构造头 - 对于
FileField或ImageField上传，仍要用Client或APIClient配合multipart/form-data——此时data应传dict而非JSON，且不能加content_type参数
from rest_framework.test import APIClient
client = APIClient()
client.post('/api/users/', {'name': 'Alice'}, format='json') # format='json'触发自动序列化
如何正确测试权限类（如IsAuthenticated或自定义权限）？
权限测试的关键是验证不同用户角色在相同端点上的响应状态码差异，而不是只测“登录用户能通过”。容易忽略的是：测试前必须调用force_authenticate()或真实登录，否则即使视图配置了IsAuthenticated，测试也会因用户为AnonymousUser而直接返回403或401，但这不反映真实流程（比如JWT过期应是401，未登录才是403取决于配置）。
- 使用
force_authenticate(client, user=user)绕过认证后端，适合快速验证权限逻辑本身 - 若测试JWT或Session真实流程，需先调用登录接口获取token，再用
credentials()设置头 - 自定义权限中若依赖
request.auth（如Token校验），force_authenticate不会设置它，此时必须走真实认证链
from rest_framework.test import force_authenticate
force_authenticate(client, user=regular_user) # 此时 request.user 有效，但 request.auth 为空
response = client.get('/api/profile/')
assert response.status_code == 200
测试序列化器时，is_valid()返回False但errors为空？
这是常见误判：调用serializer.is_valid()后，必须显式检查返回值，不能只看serializer.errors。因为serializer.errors在is_valid()未被调用时是空dict，调用后才填充；若忘记调用或调用前就访问errors，会误以为“无错误”。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 始终按顺序写：
serializer = MySerializer(data=bad_data); assert not serializer.is_valid(); assert 'email' in serializer.errors - 对于
required=False字段，空字符串''可能触发ValidationError（取决于allow_blank），不要假设空值一定跳过校验 - 测试嵌套序列化器时，
errors是嵌套字典，键名对应字段路径，例如serializer.errors['profile']['age']
data = {'email': ''}
serializer = UserSerializer(data=data)
assert not serializer.is_valid() # 必须先调用
assert 'email' in serializer.errors # 此时 errors 才有内容
数据库事务与TestCase vs TransactionTestCase
DRF测试通常用django.test.TestCase，它基于Python的unittest.TestCase并用数据库事务回滚提速；但若测试涉及atomic块、PostgreSQL的SAVEPOINT、或需要真实主键ID（如信号触发、外部服务回调），事务回滚会导致ID不连续或信号未触发，此时必须换用TransactionTestCase。
立即学习“Python免费学习笔记（深入）”；
-
TestCase快（毫秒级），适合95%的API逻辑测试 -
TransactionTestCase慢（秒级），每次测试都重建库表，仅在以下情况必要：- 测试
@transaction.atomic内异常是否回滚 - 模型
post_save信号中调用了外部HTTP请求，需验证是否真发出 - 需要断言
obj.id等于某个具体整数（事务中ID可能被复用）
- 测试
from django.test import TransactionTestCase
class OrderSignalTest(TransactionTestCase):
def test_order_created_signal_fires(self):
# 这里需要真实提交事务才能触发信号
order = Order.objects.create(total=100)
self.assertEqual(ExternalLog.objects.count(), 1) # 信号已执行
DRF单元测试真正难的不是写法，而是判断何时该用force_authenticate、何时必须走真实认证，以及哪些边界场景（如并发创建、信号、数据库约束）会绕过事务隔离——这些地方不提前想清楚，测试看似通过，实际掩盖了运行时问题。
