django-test-data

Django 测试数据

许多运行缓慢的 Django 测试套件，耗时都花在构建并不需要的数据上，或是为了测试本可在更小边界验证的行为而走完整的请求／数据库路径。使用此技能降低设置成本，同时保留有代表性的集成测试覆盖。

重构工作流

1. 梳理被测行为。

   • 找出最小且有用的边界：函数、表单、模型方法、中间件、命令辅助函数、视图或完整请求路径。
   • 保留少量集成测试来验证组件连接；将详细用例移至边界清晰的单元测试。

2. 选择最快的测试基类。

   • SimpleTestCase：不访问数据库。
   • TestCase：使用回滚的常规数据库测试。
   • TransactionTestCase：仅用于测试已提交事务的行为。
   • LiveServerTestCase：仅用于浏览器／实时服务测试。

3. 移除宽泛的固定装置数据。

   • 避免大型固定装置文件和总是创建对象的基类。
   • 只构建每个测试或类所需的数据。

4. 有目的地使用工厂。

   • 领域简单时，从小型工厂函数开始。
   • 当关系和变体变得重复时，使用 Factory Boy 或 Model Bakery。

5. 使用 setUpTestData 共享类级数据。

   • 在 TestCase 中，使用 setUpTestData() 创建供多个方法复用的数据库对象。
   • 避免在多个方法之间修改共享的内存对象。

6. 优化测试设置和断言中的数据库访问。

   • 当设置／查询成本成为瓶颈时，使用 select_related、prefetch_related 或 bulk_create。
   • 如果性能属于契约的一部分，则对高频路径断言查询次数。

阅读 patterns.md 查看示例和决策详情。

决策规则

• 如果测试不需要数据库，请使用 SimpleTestCase。
• 如果只有部分测试需要数据库，请将它们拆分到不同的类中。
• 如果测试需要已提交事务的行为，请先确认 captureOnCommitCallbacks() 或内部的 atomic() 是否足够。
• 如果许多测试共享开销较大的对象，请使用 setUpTestData 而非 setUp。
• 如果固定装置文件难以理解或不断增长，请用工厂替代。
• 如果测试依赖硬编码的自增 ID，请修正断言，而不是启用 reset_sequences=True。
• 当多条断言描述同一次高开销操作产生的一种行为时，将它们合并。

常见错误

• 只通过渲染后的 HTML 测试表单验证，而不直接检查表单错误。
• 将管理命令的业务逻辑留在 handle() 中，迫使测试通过 call_command() 执行。
• 默认使用 TransactionTestCase。
• 在基类 TestCase 中放入只有少数子类需要的数据。
• 把工厂当作每项测试都创建大型对象关系图的许可。
• 修改由 setUpTestData 创建的对象，导致内存状态泄漏到后续测试。

验证

完成重构前：

• 确保旧行为仍在合适的层级得到覆盖。
• 在有用时，将使用数据库的测试与不使用数据库的测试拆分。
• 仅在能降低成本时，才将重复设置移至 setUpTestData 或工厂。
• 确保相关测试单独运行以及作为模块／类的一部分运行时均能通过。