高度なテストトピック—Djangoドキュメント

提供：Dev Guides
< DjangoDjango/docs/3.2.x/topics/testing/advanced
移動先:案内、検索

高度なテストトピック

リクエストファクトリー

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)

AsyncRequestFactory

RequestFactoryは、WSGIのようなリクエストを作成します。 正しいASGI scopeを含む、ASGIのようなリクエストを作成する場合は、代わりにdjango.test.AsyncRequestFactoryを使用できます。

このクラスはRequestFactoryと直接API互換ですが、唯一の違いは、WSGIRequestインスタンスではなくASGIRequestインスタンスを返すことです。 そのメソッドはすべて、同期呼び出し可能です。


クラスベースのビューのテスト

要求/応答サイクルの外でクラスベースのビューをテストするには、インスタンス化後に setup（）を呼び出して、ビューが正しく構成されていることを確認する必要があります。

たとえば、次のクラスベースのビューを想定します。

views.py 

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()メソッドを直接テストできます。

tests.py 

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)

テストと複数のホスト名

：setting： `ALLOWED_HOSTS` 設定は、テストの実行時に検証されます。 これにより、テストクライアントは内部URLと外部URLを区別できます。

マルチテナンシーをサポートするか、リクエストのホストに基づいてビジネスロジックを変更し、テストでカスタムホスト名を使用するプロジェクトは、：setting： `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/', HTTP_HOST='docs.djangoproject.dev:8000')
        self.assertEqual(response.status_code, 200)

設定ファイルには、プロジェクトでサポートされているドメインのリストが含まれています。 

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

別のオプションは、 override_settings（）または modify_settings（）を使用して、必要なホストを：setting： `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/')

テストの実行時に：setting： `ALLOWED_HOSTS` チェック（ALLOWED_HOSTS = ['*']）を無効にすると、外部URLへのリダイレクトをたどった場合に、テストクライアントが有用なエラーメッセージを表示しなくなります。


テストと複数のデータベース

プライマリ/レプリカ構成のテスト

プライマリ/レプリカ（一部のデータベースではマスター/スレーブと呼ばれる）レプリケーションを使用して複数のデータベース構成をテストする場合、テストデータベースを作成するこの戦略は問題を引き起こします。 テストデータベースが作成されると、レプリケーションは行われず、その結果、プライマリで作成されたデータはレプリカに表示されません。

これを補うために、Djangoではデータベースがテストミラーであることを定義できます。 次の（簡略化された）データベース構成の例を検討してください。 

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
    }
}

このセットアップでは、2つのデータベースサーバーがあります。データベースエイリアスdefaultで記述されるdbprimaryと、エイリアスreplicaで記述されるdbreplicaです。 ご想像のとおり、dbreplicaはデータベース管理者によってdbprimaryのリードレプリカとして構成されているため、通常のアクティビティでは、defaultへの書き込みはすべてreplica。

Djangoが2つの独立したテストデータベースを作成した場合、レプリケーションが発生すると予想されていたテストはすべて中断されます。 しかしreplicaデータベースはテストミラーとして構成されています（ ：setting： `MIRROR ` テスト設定）、テスト中であることを示し、replica の鏡として扱われるべきですdefault 。

テスト環境を構成すると、replicaのテストバージョンはではなく作成されます。 代わりに、replicaへの接続はdefaultを指すようにリダイレクトされます。 その結果、defaultへの書き込みはreplicaに表示されますが、実際には同じデータベースであるため、2つのデータベース間にデータ複製があるためではありません。


テストデータベースの作成順序の制御

デフォルトでは、Djangoはすべてのデータベースがdefaultデータベースに依存していると想定しているため、常にdefaultデータベースを最初に作成します。 ただし、テストセットアップ内の他のデータベースの作成順序は保証されません。

データベース構成で特定の作成順序が必要な場合は、を使用して存在する依存関係を指定できます。 ：setting： `DEPENDENCIES ` テスト設定。 次の（簡略化された）データベース構成の例を検討してください。 

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'],
        },
    }
}

この構成では、diamondsデータベースが最初に作成されます。これは、依存関係のない唯一のデータベースエイリアスであるためです。 次にdefaultおよびclubsエイリアスが作成され（このペアの作成順序は保証されませんが）、次にhearts、最後にspadesが作成されます。

に循環依存がある場合 ：setting： `DEPENDENCIES ` 定義、 不適切に構成された例外が発生します。


TransactionTestCaseの高度な機能

TransactionTestCase.available_apps

警告

この属性はプライベートAPIです。 たとえば、アプリケーションの読み込みの変更に対応するために、将来的に非推奨期間なしで変更または削除される可能性があります。

これは、Django独自のテストスイートを最適化するために使用されます。このテストスイートには、数百のモデルが含まれていますが、異なるアプリケーションのモデル間の関係はありません。

デフォルトでは、available_appsはNoneに設定されています。 各テストの後、Djangoは：djadmin： `flush` を呼び出してデータベースの状態をリセットします。 これにより、すべてのテーブルが空になり、 post_migrate シグナルが発行されます。これにより、モデルごとに1つのコンテンツタイプと4つのアクセス許可が再作成されます。 この操作は、モデルの数に比例してコストがかかります。

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を使用してそれらを順番に実行できます。 このミックスインはファイルシステム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

それらのファイルのいくつかの内部を見てみましょう：

runtests.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テストランナーを使用するために必要な最低限のものだけが含まれています。 冗長性を制御したり、実行する特定のテストラベルを渡したりするためのコマンドラインオプションを追加することもできます。

tests / test_settings.py 

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

このファイルには、アプリのテストを実行するために必要な Django設定が含まれています。

繰り返しますが、これは最小限の例です。 テストを実行するには、追加の設定が必要になる場合があります。

tests パッケージはテストの実行時に：setting： `INSTALLED_APPS` に含まれているため、models.pyファイルでテスト専用モデルを定義できます。


さまざまなテストフレームワークを使用する

明らかに、unittestだけがPythonテストフレームワークではありません。 Djangoは代替フレームワークの明示的なサポートを提供していませんが、通常のDjangoテストであるかのように、代替フレームワーク用に構築されたテストを呼び出す方法を提供します。

./manage.py testを実行すると、Djangoは：setting： `TEST_RUNNER` 設定を調べて何をすべきかを判断します。 デフォルトでは、：setting： `TEST_RUNNER` は'django.test.runner.DiscoverRunner'を指します。 このクラスは、デフォルトのDjangoテスト動作を定義します。 この動作には次のものが含まれます。

  1. グローバルな事前テストセットアップを実行します。
  2. 名前がパターンtest*.pyと一致する現在のディレクトリの下のファイルでテストを探しています。
  3. テストデータベースの作成。
  4. migrateを実行して、モデルと初期データをテストデータベースにインストールします。
  5. システムチェックを実行します。
  6. 見つかったテストを実行します。
  7. テストデータベースを破棄します。
  8. グローバルなテスト後の分解を実行します。

独自のテストランナークラスを定義し、そのクラスで：setting： `TEST_RUNNER` をポイントすると、./manage.py testを実行するたびにDjangoがテストランナーを実行します。 このようにして、Pythonコードから実行できる任意のテストフレームワークを使用したり、Djangoテスト実行プロセスを変更してテスト要件を満たすことができます。

テストランナーの定義

テストランナーは、run_tests()メソッドを定義するクラスです。 Djangoには、デフォルトのDjangoテスト動作を定義するDiscoverRunnerクラスが付属しています。 このクラスは、run_tests()エントリポイントに加えて、run_tests()がテストスイートのセットアップ、実行、および破棄に使用する他のメソッドの選択を定義します。

class DiscoverRunner(pattern='test*.py', top_level=None, verbosity=1, interactive=True, failfast=False, keepdb=False, reverse=False, debug_mode=False, debug_sql=False, parallel=0, tags=None, exclude_tags=None, test_name_patterns=None, pdb=False, buffer=False, enable_faulthandler=True, timing=True, **kwargs)

DiscoverRunnerは、patternに一致する任意のファイルでテストを検索します。

top_levelを使用して、最上位のPythonモジュールを含むディレクトリを指定できます。 通常、Djangoはこれを自動的に把握できるため、このオプションを指定する必要はありません。 指定する場合、通常はmanage.pyファイルを含むディレクトリになります。

verbosityは、コンソールに出力される通知およびデバッグ情報の量を決定します。 0は出力なし、1は通常の出力、2は詳細出力です。

interactiveがTrueの場合、テストスイートには、テストスイートの実行時にユーザーに指示を求める権限があります。 この動作の例は、既存のテストデータベースを削除する許可を求めることです。 interactiveがFalseの場合、テストスイートは手動の介入なしで実行できる必要があります。

failfastがTrueの場合、最初のテストの失敗が検出された後、テストスイートは実行を停止します。

keepdbがTrueの場合、テストスイートは既存のデータベースを使用するか、必要に応じてデータベースを作成します。 Falseの場合、新しいデータベースが作成され、既存のデータベースが存在する場合は削除するようにユーザーに求めます。

reverseがTrueの場合、テストケースは逆の順序で実行されます。 これは、適切に分離されておらず、副作用があるテストをデバッグする場合に役立つ可能性があります。 このオプションを使用すると、テストクラスによるグループ化が保持されます。

debug_modeは、テストを実行する前に：setting： `DEBUG` 設定を設定する必要があるものを指定します。

parallelはプロセスの数を指定します。 parallelが1より大きい場合、テストスイートはparallelプロセスで実行されます。 構成されたプロセスよりもテストケースが少ない場合、Djangoはそれに応じてプロセスの数を減らします。 各プロセスは独自のデータベースを取得します。 このオプションでは、トレースバックを正しく表示するために、サードパーティのtblibパッケージが必要です。

tagsを使用して、フィルタリングテストのタグのセットを指定できます。 exclude_tagsと組み合わせることができます。

exclude_tagsを使用して、テストを除外するためのタグのセットを指定できます。 tagsと組み合わせることができます。

debug_sqlがTrueの場合、テストケースが失敗すると、 django.db.backends logger に記録されたSQLクエリとトレースバックが出力されます。 verbosityが2の場合、すべてのテストのクエリが出力されます。

test_name_patternsを使用して、テストメソッドとクラスを名前でフィルタリングするための一連のパターンを指定できます。

pdbがTrueの場合、テストエラーまたは失敗のたびにデバッガー（pdbまたはipdb）が生成されます。

bufferがTrueの場合、合格したテストからの出力は破棄されます。

enable_faulthandlerがTrueの場合、faulthandlerが有効になります。

timingがTrueの場合、データベースのセットアップや合計実行時間を含むテストのタイミングが表示されます。

Djangoは、新しい引数を追加することで、テストランナーの機能を拡張する場合があります。 **kwargs宣言により、この拡張が可能になります。 DiscoverRunnerをサブクラス化するか、独自のテストランナーを作成する場合は、**kwargsを受け入れることを確認してください。

テストランナーは、追加のコマンドラインオプションを定義することもできます。 add_arguments(cls, parser)クラスメソッドを作成またはオーバーライドし、メソッド内でparser.add_argument()を呼び出してカスタム引数を追加します。これにより、：djadmin： `test` コマンドでそれらを使用できるようになります。引数。

バージョン3.1の新機能： buffer引数が追加されました。

バージョン3.2の新機能： enable_faulthandlerおよびtiming引数が追加されました。

属性

DiscoverRunner.test_suite
テストスイートの構築に使用されるクラス。 デフォルトでは、unittest.TestSuiteに設定されています。 テストを収集するために異なるロジックを実装する場合は、これをオーバーライドできます。
DiscoverRunner.test_runner
これは、個々のテストを実行し、結果をフォーマットするために使用される低レベルのテストランナーのクラスです。 デフォルトでは、unittest.TextTestRunnerに設定されています。 命名規則の不幸な類似性にもかかわらず、これはDiscoverRunnerと同じタイプのクラスではなく、より広範な責任のセットをカバーします。 この属性をオーバーライドして、テストの実行方法とレポート方法を変更できます。
DiscoverRunner.test_loader
これは、TestCasesやモジュールなどからテストをロードし、ランナーが実行できるようにテストスイートにバンドルするクラスです。 デフォルトでは、unittest.defaultTestLoaderに設定されています。 テストが通常とは異なる方法で読み込まれる場合は、この属性をオーバーライドできます。


メソッド

DiscoverRunner.run_tests(test_labels, extra_tests=None, **kwargs)

テストスイートを実行します。

test_labelsを使用すると、実行するテストを指定でき、いくつかの形式をサポートします（サポートされている形式のリストについては、 DiscoverRunner.build_suite（）を参照してください）。

extra_testsは、テストランナーによって実行されるスイートに追加する追加のTestCaseインスタンスのリストです。 これらの追加のテストは、test_labelsにリストされているモジュールで検出されたものに加えて実行されます。

このメソッドは、失敗したテストの数を返す必要があります。

classmethod DiscoverRunner.add_arguments(parser)
このクラスメソッドをオーバーライドして、：djadmin： `test` 管理コマンドで受け入れられるカスタム引数を追加します。 パーサーに引数を追加する方法の詳細については、argparse.ArgumentParser.add_argument()を参照してください。
DiscoverRunner.setup_test_environment(**kwargs)
setup_test_environment（）を呼び出し、：setting： `DEBUG` をself.debug_mode（デフォルトはFalse）に設定して、テスト環境をセットアップします。
DiscoverRunner.build_suite(test_labels=None, extra_tests=None, **kwargs)

提供されたテストラベルに一致するテストスイートを構築します。

test_labelsは、実行するテストを説明する文字列のリストです。 テストラベルは、次の4つの形式のいずれかを取ることができます。

  • path.to.test_module.TestCase.test_method –テストケースで単一のテストメソッドを実行します。

  • path.to.test_module.TestCase –テストケースですべてのテストメソッドを実行します。

  • path.to.module –指定されたPythonパッケージまたはモジュール内のすべてのテストを検索して実行します。

  • path/to/directory –指定されたディレクトリの下にあるすべてのテストを検索して実行します。

test_labelsの値がNoneの場合、テストランナーは、名前がpatternと一致する現在のディレクトリの下のすべてのファイルでテストを検索します（上記を参照）。

extra_testsは、テストランナーによって実行されるスイートに追加する追加のTestCaseインスタンスのリストです。 これらの追加のテストは、test_labelsにリストされているモジュールで検出されたものに加えて実行されます。

実行の準備ができているTestSuiteインスタンスを返します。

DiscoverRunner.setup_databases(**kwargs)
setup_databases（）を呼び出して、テストデータベースを作成します。
DiscoverRunner.run_checks(databases)

テストdatabasesでシステムチェックを実行します。

バージョン3.1の新機能： databasesパラメーターが追加されました。

DiscoverRunner.run_suite(suite, **kwargs)

テストスイートを実行します。

テストスイートの実行によって生成された結果を返します。

DiscoverRunner.get_test_runner_kwargs()
DiscoverRunner.test_runnerをインスタンス化するためのキーワード引数を返します。
DiscoverRunner.teardown_databases(old_config, **kwargs)
teardown_databases（）を呼び出して、テストデータベースを破棄し、テスト前の状態を復元します。
DiscoverRunner.teardown_test_environment(**kwargs)
テスト前の環境を復元します。
DiscoverRunner.suite_result(suite, result, **kwargs)
テストスイートとそのテストスイートの結果に基づいてリターンコードを計算して返します。


テストユーティリティ

django.test.utils

独自のテストランナーの作成を支援するために、Djangoはdjango.test.utilsモジュールでいくつかのユーティリティメソッドを提供しています。

setup_test_environment(debug=None)

テンプレートレンダリングシステムのインストルメンテーションのインストールやダミーの電子メール送信ボックスのセットアップなど、グローバルな事前テストセットアップを実行します。

debugがNoneでない場合、：setting： `DEBUG` 設定はその値に更新されます。

teardown_test_environment()
テンプレートシステムからインストルメンテーションを削除したり、通常の電子メールサービスを復元したりするなど、グローバルなテスト後の分解を実行します。
setup_databases(verbosity, interactive, *, time_keeper=None, keepdb=False, debug_sql=False, parallel=0, aliases=None, **kwargs)

テストデータベースを作成します。

加えられた変更を元に戻すのに十分な詳細を提供するデータ構造を返します。 このデータは、テストの終了時に teardown_databases（）関数に提供されます。

aliases引数は、テストデータベースをセットアップする必要がある：setting： `DATABASES` エイリアスを決定します。 提供されていない場合、デフォルトですべての：setting： `DATABASES` エイリアスになります。

バージョン3.2で変更： time_keeper kwargが追加され、すべてのkwargがキーワードのみになりました。

teardown_databases(old_config, parallel=0, keepdb=False)

テストデータベースを破棄し、テスト前の状態を復元します。

old_configは、元に戻す必要のあるデータベース構成の変更を定義するデータ構造です。 setup_databases（）メソッドの戻り値です。


django.db.connection.creation

データベースバックエンドの作成モジュールには、テスト中に役立つユーティリティもいくつか用意されています。

create_test_db(verbosity=1, autoclobber=False, serialize=True, keepdb=False)

新しいテストデータベースを作成し、それに対してmigrateを実行します。

verbosityは、run_tests()と同じ動作をします。

autoclobberは、テストデータベースと同じ名前のデータベースが検出された場合に発生する動作について説明しています。

  • autoclobberがFalseの場合、ユーザーは既存のデータベースの破棄を承認するように求められます。 sys.exitは、ユーザーが承認しない場合に呼び出されます。

  • autoclobberがTrueの場合、データベースはユーザーに相談せずに破棄されます。

serializeは、テストを実行する前にDjangoがデータベースをメモリ内のJSON文字列にシリアル化するかどうかを決定します（トランザクションがない場合にテスト間でデータベースの状態を復元するために使用されます）。 serialized_rollback = True のテストクラスがない場合は、これをFalseに設定して、作成時間を短縮できます。

デフォルトのテストランナーを使用している場合は、 ：setting： `SERIALIZE ` のエントリ ：setting： `TEST ` 辞書。

keepdbは、テスト実行で既存のデータベースを使用するか、新しいデータベースを作成するかを決定します。 Trueの場合、既存のデータベースが使用されるか、存在しない場合は作成されます。 Falseの場合、新しいデータベースが作成され、既存のデータベースが存在する場合は削除するようにユーザーに求めます。

作成したテストデータベースの名前を返します。

create_test_db()には、：setting： `DATABASES` の：setting：` NAME` の値を、テストデータベースの名前と一致するように変更するという副作用があります。

destroy_test_db(old_database_name, verbosity=1, keepdb=False)

：setting： `DATABASES` の：setting：` NAME` の値が名前のデータベースを破棄し、：setting： `NAME` をに設定します。 old_database_nameの値。

verbosity引数の動作は、 DiscoverRunner の場合と同じです。

keepdb引数がTrueの場合、データベースへの接続は閉じられますが、データベースは破棄されません。


coverage.pyとの統合

コードカバレッジは、テストされたソースコードの量を示します。 これは、コードのどの部分がテストによって実行され、どの部分が実行されていないかを示します。 これはアプリケーションのテストの重要な部分であるため、テストの範囲を確認することを強くお勧めします。

Djangoは、Pythonプログラムのコードカバレッジを測定するためのツールである Coverage.py と簡単に統合できます。 まず、 Coverage.py をインストールします。 次に、manage.pyを含むプロジェクトフォルダーから以下を実行します。 

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

これにより、テストが実行され、プロジェクトで実行されたファイルのカバレッジデータが収集されます。 次のコマンドを入力すると、このデータのレポートを表示できます。 

coverage report

一部のDjangoコードはテストの実行中に実行されましたが、前のコマンドにsourceフラグが渡されたため、ここにはリストされていません。

欠落した行の詳細を示す注釈付きHTMLリストなどのその他のオプションについては、 Coverage.py ドキュメントを参照してください。



「https://www.finddevguides.com/index.php?title=Django/docs/3.2.x/topics/testing/advanced&oldid=96574」から取得
Powered by MediaWiki