django-test-performance

Django 测试性能

将其用作加速 Django 测试套件的编排技能。不要一开始就盲目修改设置；先测量测试套件，再选择最小且安全的优化，并使用可重复执行的命令验证。

核心工作流

1. 建立基线。

   • 运行开发者或 CI 使用的同一条命令。
   • 记录实际运行时间、运行器、设置模块、数据库后端、工作进程数和分支。
   • 如果原因不明确，请先使用 django-test-profiling，再更改行为。

2. 判断主要耗时来源。

   • 启动／导入／发现：缩小收集范围，并减少开销大的应用初始化。
   • 数据库创建／迁移：在本地复用数据库、压缩迁移历史，或改进数据库存储。
   • 单项测试设置：减少测试数据、使用工厂，并采用 setUpTestData。
   • 外部后端：将文件存储、缓存、任务队列和检测工具替换为适用于测试的后端。
   • 耗时较长的测试：完成隔离检查后再并行运行。

3. 优先采用低风险的优化。

   • 使用快速密码哈希器。
   • 在测试中设置 DEBUG = False。
   • 如果不需要序列化回滚，则禁用数据库序列化。
   • 禁用调试工具栏、Sentry/Rollbar/APM 初始化以及其他检测工具。
   • 为存储、缓存和任务队列使用内存或本地测试后端。
   • 参见 speed-wins.md。

4. 改进数据和结构。

   • 使用 django-test-data 处理工厂、固定数据、setUpTestData、TestCase，以及集成测试与单元测试的选择。

5. 改进迁移和数据库设置。

   • 本地重复运行时使用 --keepdb 或 --reuse-db。
   • 迁移历史变更时强制重建。
   • 优先压缩迁移，而不是全局禁用迁移。
   • 除非项目与数据库无关，否则测试数据库后端应尽量接近生产环境。

6. 仅在安全时并行运行。

   • 使用 django-test-parallelization 处理顺序隔离、共享资源和工作进程配置。

7. 使用原始基线命令重新测量。

   • 报告优化前后的运行时间，以及变更带来的风险范围。
   • 根据测得的影响和行为保真度，保留或撤销每项优化。

默认命令

time python manage.py test
python manage.py test --timing
python manage.py test --keepdb

time pytest
pytest --durations 20
pytest --reuse-db
pytest --create-db

决策规则

• 如果无法指出瓶颈，先进行性能分析。
• 如果某项设置会改变类似生产环境的行为，请将覆盖范围限制在最小范围，并说明测试为何仍具有代表性。
• 避免在应用代码中广泛使用 TESTING = True 分支；应使用明确的设置和测试辅助工具。
• 不要仅为提速就将 PostgreSQL/MySQL/MariaDB 项目切换到 SQLite，除非生产环境使用 SQLite，或项目有意支持多种后端。
• 不要将禁用迁移作为常规做法。如果旧项目坚持如此，CI 中仍须运行真实迁移。
• 避免本地提速捷径掩盖 CI 覆盖范围。CI 应在某处运行耗时较长的测试，以及符合真实迁移情况的测试路径。

移交指南

情况	使用
需要计时结果、慢速测试列表、火焰图或 cProfile 输出	django-test-profiling
启用 --parallel、pytest-xdist 或排查随机失败	django-test-parallelization
固定数据过多、工厂、setUpTestData、TestCase 类选择	django-test-data
安全地模拟设置、HTTP、时间、输出或命令输入	django-targeted-mocking
CI 缓存、拆分任务、慢速标记、运行器规模	django-ci-test-optimization

验证

完成前，请提供：

• 使用同一条命令测得的基线和最终运行时间。
• 按优先级排列的已实施或建议变更清单。
• 每项仅用于测试的覆盖所引入的风险。
• 项目应保留用于本地和 CI 验证的命令。