Django测试单文件运行正常 用DiscoverRunner批量运行报错如何解决

• 全局状态跨文件泄露：mail.outbox是Django维护的全局内存对象，测试框架默认仅在单个测试方法、单个测试类执行完成后自动清空该对象。DiscoverRunner默认按文件路径字母序批量执行测试，两个依赖mail.outbox的测试文件分属不同包时，执行顺序靠后的文件会读取到前一个文件残留的邮件数据，触发断言失败。放在同一个包后，Django会对同包下的测试统一做全局状态重置，因此问题消失。
• 测试数据残留冲突：批量运行时如果多个测试类加载的fixtures存在重复主键、或前序测试修改了公共表数据但事务回滚异常，单独运行时数据库每次重建无冲突，批量运行时残留数据会导致后续测试查询结果不符合预期。
• 运行配置不一致：PyCharm单独运行测试时会默认适配当前文件的Django配置，可能默认开启--keepdb、使用独立测试数据库配置，和DiscoverRunner的默认运行参数不一致，导致批量运行时的缓存、数据库状态和单独运行时有差异。

• 验证状态泄露问题：运行测试时添加--reverse参数倒序执行，如果报错的用例位置发生变化，即可确认是跨用例状态泄露导致的问题。针对邮件相关测试，在所有用到mail.outbox的测试类的setUp方法中手动清空全局发件箱：

  from django.core import mail
  def setUp(self):
      mail.outbox.clear()
      super().setUp()
  

• 排查fixtures与数据残留：运行测试时添加--failfast参数，拿到第一个报错的用例后，单独运行该用例及它执行顺序之前的3-5个用例，确认是否是前序用例残留数据导致的报错。如果确认是数据库数据残留，可在测试类中添加serialized_rollback = True属性，强制Django在测试类执行完后全量回滚数据库到初始状态：

  from django.test import TestCase
  class YourTestCase(TestCase):
      serialized_rollback = True
      fixtures = ["your_fixture.json"]
  

• 对齐运行配置：对比PyCharm测试运行配置中的环境变量、启动参数，和命令行调用DiscoverRunner的参数，确保两边的DJANGO_SETTINGS_MODULE、测试数据库配置、--keepdb/--reuse-db等参数完全一致，排除配置差异导致的结果不一致。
• 检查测试包初始化逻辑：查看不同测试子包的__init__.py文件，确认是否存在自定义的配置初始化、fixture注册逻辑，跨包的初始化逻辑差异也可能导致同一份用例在不同包下运行结果不同。

内容的提问来源于stack exchange，提问作者shivan