在 django 1.5 和更早的版本中，运行 python manage.py test 默认会运行项目中的所有测试（包括 django.contrib 中的所有测试）。在 1.6 版本之后，默认行为是运行当前目录中的所有测试。
运行所有测试的最佳方式是什么（v 1.6），无论有没有 django.contrib 测试？
【问题讨论】：
标签： django testing django-testing django-1.6
Django 1.6 changed the default test runner 到：
TEST_RUNNER = 'django.test.runner.DiscoverRunner'
您可以通过添加到您的 settings.py 来恢复旧行为：
TEST_RUNNER = 'django.test.simple.DjangoTestSuiteRunner'
如发行说明中所述：
之前的运行程序 (django.test.simple.DjangoTestSuiteRunner) 仅在 INSTALLED_APPS 中 Python 包的 models.py 和 tests.py 模块中发现测试。
新的运行程序 (django.test.runner.DiscoverRunner) 使用 unittest2（Python 2.7+ 标准库中的 unittest 版本，与 Django 捆绑）中内置的测试发现功能。通过测试发现，测试可以位于名称与模式 test*.py 匹配的任何模块中。
新的运行器需要一个点路径的模块列表，可以在其中发现测试，因此您也可以通过这种方式从django contrib 运行测试：
python manage.py test myproject django.contrib path.to.someotherapp
这将不会自动运行来自INSTALLED_APPS 中应用程序的所有测试。对于更复杂的解决方案，您可以编写自己的跑步者，从旧跑步者和新跑步者中获取。
还请注意，通常不需要从django.contrib 运行测试，因为这些不是测试您的应用程序，而是测试 Django 发行版。 Django 附带了更多的测试，这些测试不是由任何一个运行器运行的。
【讨论】：
django.contrib 作为参数传递给 test command ，如我更新的答案中所述。但这不会运行所有应用程序。
python manage.py test myproject 继续为我运行 0 个测试。这只是我的配置吗？
python manage.py test myproject 是正确的，如果 myproject 是当前目录中的一个包。您的测试模块是否命名为test*.py？命令find myproject -name 'test*.py' 是否找到您的测试？
manage.py test myproject 将在 myproject 目录下查找 test*.py。但它不会去我的每个应用程序中寻找测试。似乎需要以某种方式将 INSTALLED_APPS 分成两个变量（MY_APPS、CONTRIB_APPS），然后将 MY_APPS 列表传递给测试运行程序？
很遗憾 Django 决定忽略 INSTALLED_APPS 中不在项目树中的自定义应用程序。有关他们的推理，请参阅此帖子 https://groups.google.com/forum/#!topic/django-users/gGfVhfrfE10。
我的实际案例当然不属于上面提到的三个用例（大惊喜！）：我们有一个网站，我们为客户/客户组部署了不同的紧密耦合定制应用程序集合。我们不希望这些应用程序嵌套在项目树下，因为每个应用程序都在自己的 git 存储库中。过去，我们使用过 git 子模块、假子模块和子树；在我们的设置中都有他们的问题。另一方面，将每个应用作为自己的包与网站处于同一级别，这可以满足我们的大部分要求。
当然，每个应用程序都有自己的测试，但我希望能够为每个特定的不同构成站点运行完整的测试套件（包括站点和所有自定义应用程序）。
我们的解决方法如下：
在settings/test.py 我有：
ATA_BLACKLIST = ['scary_mod1', 'scary_mod2']
ADD_TEST_APPS = [i for i in INSTALLED_APPS
if '.' not in i and i not in ATA_BLACKLIST]
ATA_STR = " ".join(ADD_TEST_APPS)
我在顶层有一个 run_tests.sh 脚本，看起来或多或少像这样：
#!/bin/bash
MYDIR=`dirname $0`
cd $MYDIR
DJANGO_SETTINGS_MODULE=kmxng.settings.test
ATA_STR=`python -c "from django.conf import settings; print settings.ATA_STR"`
coverage run --omit "*lib/python*" ./manage.py test . $ATA_STR
coverage report
简而言之，在我的测试设置中，我生成了一个应该添加到测试中的额外模块列表。除了默认的 . 之外，我还使用该列表调用 django test 命令。
（我确实看过覆盖 DiscoverRunner ——它有一个相对较长的 build_suite 方法可以被覆盖。上面的解决方法是一个侵入性较小的选项。）
【讨论】：