我维护一个可安装的Django应用程序,其中包括一个常规测试套件。
当项目作者为他们的网站运行manage.py test
时,自然就足够了,他们自己的应用程序以及任何第三方安装的应用程序(例如我的)的测试都会运行。
我看到的问题是,在几种不同的情况下,用户的特定settings.py
将包含导致我的应用程序测试失败的配置。
几个例子:
我想尝试找出一种合理的方法来隔离我的测试运行的环境,以避免这种情况。
我现在的计划是让我的所有TestCase类扩展一个基础TestCase,overrides the settings,以及我可能需要处理的任何其他环境设置。
我的问题是:
INSTALLED_APPS
)实际上可能不会以预期的方式影响环境,这是正确的。它是否正确?我需要注意哪些设置,以及可能不会按预期影响全局缓存的环境信息?更一般地说,我也对任何有关其他第三方可安装应用程序存在多少问题的背景感兴趣,或者是否有任何计划在核心中进一步解决这些问题。我见过IRC关于类似问题的谈话,例如。一些Django的contrib应用程序在意外的设置配置下运行。我似乎还记得几次与第三方应用程序和django contrib应用程序遇到类似情况,所以感觉我并不是唯一一个面对这类问题的人,但目前尚不清楚是否就这是否存在共识需要更多工作或者现状足够好的事情。
请注意:
DJANGO_SETTINGS_MODULE
用于测试。答案 0 :(得分:3)
Jezdez使用的一种很好的隔离方法是使用一个名为my_app.tests
的子模块,其中包含所有测试代码(example)。这意味着当有人安装你的应用程序时,默认情况下不运行这些测试,因此他们不会得到随机幻像测试失败,但是如果他们想要检查他们是否没有无意中破坏某些东西那么就像添加{{1到myapp.tests
让它运行。
在测试中,您可以尽力确保使用INSTALLED_APPS
存在正确的环境(如果这不在1.4中那么就没有那么多代码)。就个人而言,我的感觉是,对于集成类型测试,如果它们失败也许并不重要。如果您愿意,可以包含一个干净的设置文件(compressor.test_settings
),对于一个主要项目可能更合适。
另一种方法是你将测试分开一点 - override_settings
有两个独立的测试体,contrib.admin
的测试和django.contrib.admin.tests
的测试(或某些路径)那)。检查公共api和核心功能(应该)的是第一个,并且任何可能被其他人的(合理的)配置破坏的东西都在第二个。
答案 1 :(得分:2)
由于您发布了可重复使用的第三方应用程序,因此我认为使用该应用程序的开发人员不应该更改代码。如果代码没有改变,开发人员不需要运行测试。
最好的解决方案IMO是让测试位于可安装包之外。当您安装Django并运行manage.py tests
时,您不会运行Django测试套件,因为您相信您安装的Django版本是稳定的。对于使用您的第三方应用程序的开发人员来说,这应该是相同的。
如果您希望确保特定设置可以确保您的库工作,只需编写使用这些设置值的测试用例。
这是一个可重用的django应用程序示例,它将测试放在已安装的软件包之外:
https://github.com/Yipit/django-roughage/tree/master
这是开发python模块的一种流行方式: