将Django的系统检查合并到单元测试套件中？

Question

我最近在我们的登台环境中部署了一些损坏的代码。新代码失败Django's system checks（下面复制了错误消息，不过这个问题更一般）。我们的单元测试套件运行得很干净。我的问题是：在部署代码之前，什么是确保系统检查运行的正确方法？在

最初我猜测测试可以在不执行系统检查的情况下运行，因为我们使用pytest而不是Django的测试运行器。但是，添加一个简单的测试并调用manage.py test表明Django测试运行器也可以在不执行系统检查的情况下运行。在

我的一个想法是在我们的构建管道中运行manage.py check命令，并在非零返回值的基础上使构建失败。这种方法的一个缺点是，它会在提交代码之前引入另一个开发步骤（例如，除了运行单元测试套件之外，还记得运行manage.py check）。在

另一个想法是添加一个运行系统检查的单元测试。这在技术上似乎可行，但它是否符合Django的系统检查框架的目的和设计？在

我注意到the documentation有一节是关于为自定义检查编写测试的，这并不能完全理解我的要求。我在Django文档中没有看到其他关于将系统检查合并到测试中的文档。在

错误消息：

SystemCheckError: System check identified some issues:

ERRORS:
myapp.MyCoolModel.linked_groups: (fields.E304) Reverse accessor for 'MyCoolModel.linked_groups' clashes with reverse accessor for 'MyCoolModel.primary_group'.
    HINT: Add or change a related_name argument to the definition for 'MyCoolModel.linked_groups' or 'MyCoolModel.primary_group'.
myapp.MyCoolModel.primary_group: (fields.E304) Reverse accessor for 'MyCoolModel.primary_group' clashes with reverse accessor for 'MyCoolModel.linked_groups'.
    HINT: Add or change a related_name argument to the definition for 'MyCoolModel.primary_group' or 'MyCoolModel.linked_groups'.

Answer 1

根据this ticket，在测试中不运行检查是版本1.8中引入的一种回归，最近已得到修复。在

如前所述，一个简单的解决方案似乎是创建您自己的test runner，在run_suite()的开头插入一个call_command('check')。有关示例，请参见actual fix。在