请求工厂¶

class RequestFactory[source]¶

RequestFactory 的 API 与测试客户端的 API 相同。但是，它不像浏览器那样工作，RequestFactory 提供了一种生成请求实例的方法，该实例可以用作任何视图的第一个参数。这意味着您可以像测试任何其他函数一样测试视图函数——作为一个黑盒，具有精确已知的输入，测试特定的输出。

RequestFactory 的 API 是测试客户端 API 的一个略微受限的子集。

• 它只能访问 HTTP 方法 get()、post()、put()、delete()、head()、options() 和 trace()。

• 这些方法接受所有相同的参数，除了follow。由于这只是一个用于生成请求的工厂，因此由您来处理响应。

• 它不支持中间件。如果视图正常运行需要会话和身份验证属性，则必须由测试本身提供。

from django.contrib.auth.models import AnonymousUser, User
from django.test import RequestFactory, TestCase

from .views import MyView, my_view


class SimpleTest(TestCase):
    def setUp(self):
        # Every test needs access to the request factory.
        self.factory = RequestFactory()
        self.user = User.objects.create_user(
            username="jacob", email="jacob@…", password="top_secret"
        )

    def test_details(self):
        # Create an instance of a GET request.
        request = self.factory.get("/customer/details")

        # Recall that middleware are not supported. You can simulate a
        # logged-in user by setting request.user manually.
        request.user = self.user

        # Or you can simulate an anonymous user by setting request.user to
        # an AnonymousUser instance.
        request.user = AnonymousUser()

        # Test my_view() as if it were deployed at /customer/details
        response = my_view(request)
        # Use this syntax for class-based views.
        response = MyView.as_view()(request)
        self.assertEqual(response.status_code, 200)

测试基于类的视图¶

为了在请求/响应周期之外测试基于类的视图，您必须确保它们已正确配置，方法是在实例化后调用setup()。

例如，假设以下基于类的视图

from django.views.generic import TemplateView


class HomeView(TemplateView):
    template_name = "myapp/home.html"

    def get_context_data(self, **kwargs):
        kwargs["environment"] = "Production"
        return super().get_context_data(**kwargs)

您可以通过首先实例化视图，然后将request 传递给setup()，然后继续执行测试代码来直接测试get_context_data() 方法。

from django.test import RequestFactory, TestCase
from .views import HomeView


class HomePageTest(TestCase):
    def test_environment_set_in_context(self):
        request = RequestFactory().get("/")
        view = HomeView()
        view.setup(request)

        context = view.get_context_data()
        self.assertIn("environment", context)

测试和多个主机名¶

运行测试时会验证ALLOWED_HOSTS 设置。这允许测试客户端区分内部和外部 URL。

支持多租户或根据请求的主机更改业务逻辑并在测试中使用自定义主机名的项目必须在其ALLOWED_HOSTS 中包含这些主机。

第一个选择是将主机添加到您的设置文件。例如，docs.djangoproject.com 的测试套件包含以下内容：

from django.test import TestCase


class SearchFormTestCase(TestCase):
    def test_empty_get(self):
        response = self.client.get(
            "/en/dev/search/",
            headers={"host": "docs.djangoproject.dev:8000"},
        )
        self.assertEqual(response.status_code, 200)

并且设置文件包含项目支持的域列表。

ALLOWED_HOSTS = ["www.djangoproject.dev", "docs.djangoproject.dev", ...]

另一个选择是使用override_settings() 或modify_settings() 将所需的主机添加到ALLOWED_HOSTS。对于无法打包自己的设置文件的独立应用程序，或者对于域列表不是静态的项目（例如，多租户的子域），此选项可能更好。例如，您可以为域http://otherserver/编写如下测试：

from django.test import TestCase, override_settings


class MultiDomainTestCase(TestCase):
    @override_settings(ALLOWED_HOSTS=["otherserver"])
    def test_other_domain(self):
        response = self.client.get("http://otherserver/foo/bar/")

在运行测试时禁用ALLOWED_HOSTS 检查（ALLOWED_HOSTS = ['*']）将阻止测试客户端在您重定向到外部 URL 时引发有用的错误消息。

测试和多个数据库¶

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.mysql",
        "NAME": "myproject",
        "HOST": "dbprimary",
        # ... plus some other settings
    },
    "replica": {
        "ENGINE": "django.db.backends.mysql",
        "NAME": "myproject",
        "HOST": "dbreplica",
        "TEST": {
            "MIRROR": "default",
        },
        # ... plus some other settings
    },
}

DATABASES = {
    "default": {
        # ... db settings
        "TEST": {
            "DEPENDENCIES": ["diamonds"],
        },
    },
    "diamonds": {
        # ... db settings
        "TEST": {
            "DEPENDENCIES": [],
        },
    },
    "clubs": {
        # ... db settings
        "TEST": {
            "DEPENDENCIES": ["diamonds"],
        },
    },
    "spades": {
        # ... db settings
        "TEST": {
            "DEPENDENCIES": ["diamonds", "hearts"],
        },
    },
    "hearts": {
        # ... db settings
        "TEST": {
            "DEPENDENCIES": ["diamonds", "clubs"],
        },
    },
}

TransactionTestCase 的高级功能¶

TransactionTestCase.available_apps¶

警告

此属性是一个私有 API。将来可能会在不经过弃用期的情况下更改或删除它，例如为了适应应用程序加载的更改。

它用于优化 Django 自身的测试套件，该套件包含数百个模型，但在不同应用程序中的模型之间没有关系。

默认情况下，available_apps 设置为 None。每次测试后，Django 都会调用 flush 来重置数据库状态。这会清空所有表并发出 post_migrate 信号，该信号会为每个模型重新创建一个内容类型和四个权限。此操作的成本会随着模型数量的增加而线性增长。

将 available_apps 设置为应用程序列表会指示 Django 仅将这些应用程序中的模型视为可用。 TransactionTestCase 的行为将如下更改

• post_migrate 在每次测试之前都会被触发，以创建可用应用程序中每个模型的内容类型和权限（如果缺失）。

• 每次测试后，Django 只会清空与可用应用程序中的模型对应的表。但是，在数据库级别，截断可能会级联到不可用应用程序中的相关模型。此外，post_migrate 不会被触发；它将在下一个 TransactionTestCase 选择正确的应用程序集后被触发。

由于数据库没有完全刷新，如果测试创建了未包含在 available_apps 中的模型实例，它们将泄漏，并可能导致不相关的测试失败。小心使用会话的测试；默认会话引擎将它们存储在数据库中。

由于在刷新数据库后不会发出 post_migrate，因此 TransactionTestCase 后的状态与 TestCase 后的状态不同：缺少由 post_migrate 的监听器创建的行。考虑到 测试执行顺序，如果给定测试套件中的所有 TransactionTestCase 都声明了 available_apps，或者都没有声明，则这不是问题。

available_apps 在 Django 自身的测试套件中是必需的。

TransactionTestCase.reset_sequences¶

在 TransactionTestCase 上设置 reset_sequences = True 将确保在测试运行之前始终重置序列。

class TestsThatDependsOnPrimaryKeySequences(TransactionTestCase):
    reset_sequences = True

    def test_animal_pk(self):
        lion = Animal.objects.create(name="lion", sound="roar")
        # lion.pk is guaranteed to always be 1
        self.assertEqual(lion.pk, 1)

除非您明确测试主键序列号，否则建议您不要在测试中硬编码主键值。

使用 reset_sequences = True 会降低测试速度，因为主键重置是一个相对昂贵的数据库操作。

强制按顺序运行测试类¶

如果您有无法并行运行的测试类（例如，因为它们共享一个公共资源），您可以使用 django.test.testcases.SerializeMixin 按顺序运行它们。此 mixin 使用文件系统 lockfile。

例如，您可以使用 __file__ 来确定继承自 SerializeMixin 的同一文件中的所有测试类将按顺序运行。

import os

from django.test import TestCase
from django.test.testcases import SerializeMixin


class ImageTestCaseMixin(SerializeMixin):
    lockfile = __file__

    def setUp(self):
        self.filename = os.path.join(temp_storage_dir, "my_file.png")
        self.file = create_file(self.filename)


class RemoveImageTests(ImageTestCaseMixin, TestCase):
    def test_remove_image(self):
        os.remove(self.filename)
        self.assertFalse(os.path.exists(self.filename))


class ResizeImageTests(ImageTestCaseMixin, TestCase):
    def test_resize_image(self):
        resize_image(self.file, (48, 48))
        self.assertEqual(get_image_size(self.file), (48, 48))

使用 Django 测试运行器测试可重用应用程序¶

如果您正在编写一个 可重用应用程序，您可能希望使用 Django 测试运行器来运行您自己的测试套件，从而受益于 Django 测试基础设施。

一个常见的做法是在应用程序代码旁边放一个名为 tests 的目录，其结构如下：

runtests.py
polls/
    __init__.py
    models.py
    ...
tests/
    __init__.py
    models.py
    test_settings.py
    tests.py

让我们来看看其中几个文件的内容：

#!/usr/bin/env python
import os
import sys

import django
from django.conf import settings
from django.test.utils import get_runner

if __name__ == "__main__":
    os.environ["DJANGO_SETTINGS_MODULE"] = "tests.test_settings"
    django.setup()
    TestRunner = get_runner(settings)
    test_runner = TestRunner()
    failures = test_runner.run_tests(["tests"])
    sys.exit(bool(failures))

这是您用来运行测试套件的脚本。它设置 Django 环境，创建测试数据库并运行测试。

为了清晰起见，此示例仅包含使用 Django 测试运行器所需的最低限度内容。您可能希望添加命令行选项来控制详细程度，传递要运行的特定测试标签等。

SECRET_KEY = "fake-key"
INSTALLED_APPS = [
    "tests",
]

此文件包含运行应用程序测试所需的 Django 设置。

同样，这是一个最小示例；您的测试可能需要其他设置才能运行。

由于在运行测试时 tests 包包含在 INSTALLED_APPS 中，因此您可以在其 models.py 文件中定义仅供测试使用的模型。

使用不同的测试框架¶

显然，unittest 不是唯一的 Python 测试框架。虽然 Django 没有为替代框架提供明确的支持，但它确实提供了一种方法，可以将为替代框架构建的测试调用为普通的 Django 测试。

当您运行 ./manage.py test 时，Django 会查看 TEST_RUNNER 设置以确定要执行的操作。默认情况下，TEST_RUNNER 指向 'django.test.runner.DiscoverRunner'。此类定义了默认的 Django 测试行为。此行为包括：

1. 执行全局预测试设置。

2. 在当前目录下查找名称与模式 test*.py 匹配的任何文件中的测试。

3. 创建测试数据库。

4. 运行 migrate 以将模型和初始数据安装到测试数据库中。

5. 运行 系统检查。

6. 运行找到的测试。

7. 销毁测试数据库。

8. 执行全局后测试拆卸。

如果您定义了自己的测试运行器类并将 TEST_RUNNER 指向该类，则无论何时运行 ./manage.py test，Django 都会执行您的测试运行器。通过这种方式，可以使用任何可以从 Python 代码执行的测试框架，或者修改 Django 测试执行过程以满足您可能拥有的任何测试要求。

与 coverage.py 集成¶

代码覆盖率描述了有多少源代码经过测试。它显示了测试正在执行代码的哪些部分，以及哪些部分没有执行。它是应用程序测试的重要组成部分，因此强烈建议检查测试的覆盖率。

Django 可以轻松地与 coverage.py 集成，这是一个用于测量 Python 程序代码覆盖率的工具。首先，安装 coverage。接下来，从包含 manage.py 的项目文件夹中运行以下命令：

coverage run --source='.' manage.py test myapp

这将运行您的测试并收集项目中已执行文件的覆盖率数据。您可以通过键入以下命令查看此数据的报告：

coverage report

请注意，在运行测试时执行了一些 Django 代码，但由于传递给先前命令的 source 标志，此处未列出这些代码。

有关更多选项（例如详细说明未覆盖行的带注释的 HTML 列表），请参阅 coverage.py 文档。