我维护一个可安装的 Django 应用程序,其中包括一个常规测试套件。
当项目作者为他们的站点运行时,自然而然manage.py test
地,他们自己的应用程序以及任何第三方安装的应用程序(例如我的应用程序)的测试都将运行。
我看到的问题是,在几种不同的情况下,用户的特定settings.py
信息将包含导致我的应用程序测试失败的配置。
几个例子:
- 一些测试需要检查返回的错误信息。这些错误消息使用国际化框架,因此如果站点语言不是英语,那么这些测试将失败。
- 一些测试需要检查特定的模板输出。如果站点正在使用自定义模板(应用程序支持),那么测试将最终使用他们的自定义模板而不是默认模板,并且测试将再次失败。
我想尝试找出一种明智的方法来隔离我的测试运行的环境,以避免这种情况。
我目前的计划是让我所有的 TestCase 类扩展一个基本的 TestCase,它会覆盖 settings以及我可能需要处理的任何其他环境设置。
我的问题是:
- 这是应用程序级测试环境隔离的最佳方法吗?有没有我错过的替代方案?
- 看起来我一次只能覆盖一个设置,理想情况下我可能想要一个完全干净的配置。有没有办法做到这一点,如果没有,我需要确保设置哪些主要设置才能进行基本的干净设置?
- 我相信我的说法是正确的,
INSTALLED_APPS
由于实现细节和全局状态问题,覆盖某些设置可能实际上不会以预期的方式影响环境。它是否正确?我需要注意哪些设置,哪些全局缓存的环境信息可能不会按预期受到影响? - 除了设置之外,我还需要确保什么其他环境状态是干净的?
更一般地说,我也对任何关于这对于其他第三方可安装应用程序有多大问题的上下文感兴趣,或者是否有任何计划进一步解决核心问题。我在 IRC 上看到过关于类似问题的对话,例如。一些 Django 的 contrib 应用程序在意外的设置配置下运行。我似乎还记得几次使用第三方应用程序和 django contrib 应用程序都遇到过类似的情况,所以感觉我并不是唯一一个面临此类问题的人,但目前尚不清楚是否就这是否达成共识需要更多工作或现状是否足够好的事情。
注意:
- 这些是集成级别的测试,所以我想在全局级别解决这些环境问题。
- 我需要支持 Django 1.3,但可以放入一些兼容性包装器,只要我不重新实现大量 Django 代码。
- 显然,由于这是一个可安装的应用程序,我不能只指定我自己
DJANGO_SETTINGS_MODULE
的用于测试。