请求工厂¶

class RequestFactory¶

RequestFactory 与测试客户端共享相同的 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", ...]

另一种选择是使用 ALLOWED_HOSTS 将所需主机添加到 override_settings() 或 modify_settings() 中。此选项对于无法打包其自身设置文件或域列表不是静态的项目（例如，多租户的子域）中的独立应用程序可能更可取。例如，您可以为域 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 在每个测试之前触发，为 available apps 中的每个模型创建内容类型和权限（如果它们不存在）。
• 在每个测试之后，Django 仅清空与 available apps 中的模型对应的表。但是，在数据库级别，截断可能会级联到 unavailable apps 中的相关模型。此外，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 来顺序运行它们。此混入使用文件系统 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 集成，coverage.py 是用于测量 Python 程序代码覆盖率的工具。首先，安装 coverage。接下来，从包含 manage.py 的项目文件夹中运行以下内容

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

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

coverage report

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

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