請求工廠¶

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)

您可以直接測試 get_context_data() 方法，方法是先實例化視圖，然後將 request 傳遞至 setup()，然後繼續您的測試程式碼

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 指向該類別，Django 將在您執行 ./manage.py test 時執行您的測試執行器。這樣一來，就可以使用任何可以從 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 文件。