RequestFactory はテストクライアントと同じ API を共有しています。しかし、ブラウザのように動作するのではなく、 RequestFactory は任意のビューの最初の引数として使用できるリクエストインスタンスを生成する方法を提供します。つまり、ビュー関数を他の関数をテストするのと同じ方法で テストできます。入力が完全にわかっているブラックボックスとして、特定の出力をテストできます。
RequestFactory の API は、テストクライアント API の少し制限されたサブセットです:
RequestFactoryは、HTTPメソッドの get(), post(), put(), delete(), head(), options(), trace() にだけアクセスできます。
これらのメソッドは follow 以外 はすべて同じ引数を受け取ります。これはリクエストを生成するための単なるファクトリ（工場）なので、 レスポンスの処理はあなた次第です。
ミドルウェアはサポートしていません。セッション属性と認証属性は、ビューが正しく機能するために必要であれば、テスト自身が持たなければなりません。
以下はリクエスト・ファクトリを使ったユニットテストです:
\nfrom django.contrib.auth.models import AnonymousUser, User\nfrom django.test import RequestFactory, TestCase\n\nfrom .views import MyView, my_view\n\n\nclass SimpleTest(TestCase):\n def setUp(self):\n # Every test needs access to the request factory.\n self.factory = RequestFactory()\n self.user = User.objects.create_user(\n username="jacob", email="jacob@…", password="top_secret"\n )\n\n def test_details(self):\n # Create an instance of a GET request.\n request = self.factory.get("/customer/details")\n\n # Recall that middleware are not supported. You can simulate a\n # logged-in user by setting request.user manually.\n request.user = self.user\n\n # Or you can simulate an anonymous user by setting request.user to\n # an AnonymousUser instance.\n request.user = AnonymousUser()\n\n # Test my_view() as if it were deployed at /customer/details\n response = my_view(request)\n # Use this syntax for class-based views.\n response = MyView.as_view()(request)\n self.assertEqual(response.status_code, 200)\nRequestFactory は WSGI ライクなリクエストを作成します。正しい ASGI scope を持つなど、ASGI ライクなリクエストを作成したい場合は、代わりに django.test.AsyncRequestFactory が使用できます。
このクラスは RequestFactory と直接 API 互換ですが、唯一の違いは WSGIRequest インスタンスではなく ASGIRequest インスタンスを返すことです。そのメソッドはすべて同期呼び出し可能オブジェクトのままです。
defaults 内の任意のキーワード引数は直接ASGIスコープに追加されます。
リクエスト/レスポンスサイクルの外でクラスベースのビューをテストするには、インスタンス化後に setup() を呼び出して、正しく設定されていることを確認する必要があります。
たとえば、以下のようなクラスベースのビューを想定します:
\nviews.pyfrom django.views.generic import TemplateView\n\n\nclass HomeView(TemplateView):\n template_name = "myapp/home.html"\n\n def get_context_data(self, **kwargs):\n kwargs["environment"] = "Production"\n return super().get_context_data(**kwargs)\nget_context_data() メソッドを直接テストするには、まずビューをインスタンス化して setup() に request を渡します:
tests.pyfrom django.test import RequestFactory, TestCase\nfrom .views import HomeView\n\n\nclass HomePageTest(TestCase):\n def test_environment_set_in_context(self):\n request = RequestFactory().get("/")\n view = HomeView()\n view.setup(request)\n\n context = view.get_context_data()\n self.assertIn("environment", context)\nALLOWED_HOSTS 設定はテストを実行する際に検証されます。これによりテストクライアントが内部 URL と外部 URL を区別できるようになります。
マルチテナントをサポートするプロジェクトや、リクエストのホストに基づいてビジネスロジックを変更するプロジェクトで、カスタムホスト名をテストで使用する場合は、それらのホストを ALLOWED_HOSTS に含める必要があります。
そのための最初の選択肢は、hosts を設定ファイルに追加することです。例えば、docs.djangoproject.com のテストスイートには以下が含まれています:
\nfrom django.test import TestCase\n\n\nclass SearchFormTestCase(TestCase):\n def test_empty_get(self):\n response = self.client.get(\n "/en/dev/search/",\n headers={"host": "docs.djangoproject.dev:8000"},\n )\n self.assertEqual(response.status_code, 200)\nそして設定ファイルには、プロジェクトがサポートするドメインのリストが含まれています:
\nALLOWED_HOSTS = ["www.djangoproject.dev", "docs.djangoproject.dev", ...]\n2つめの選択肢は、 override_settings() や modify_settings() を使って、 ALLOWED_HOSTS に必要なホストを追加する方法です。この方法は、独自の設定ファイルをパッケージ化できないスタンドアロンアプリや、ドメインのリストが静的でないプロジェクト (例えば、マルチテナンシー用のサブドメイン) には適しているかもしれません。たとえば、ドメイン http://otherserver/ に対して次のようなテストを書くことができます:
from django.test import TestCase, override_settings\n\n\nclass MultiDomainTestCase(TestCase):\n @override_settings(ALLOWED_HOSTS=["otherserver"])\n def test_other_domain(self):\n response = self.client.get("http://otherserver/foo/bar/")\nテストの実行時に ALLOWED_HOSTS チェック (ALLOWED_HOSTS = ['*']) を無効にすると、外部 URL へのリダイレクトを辿ったときにテストクライアントが役立つエラーメッセージを表示しないようになります。
プライマリ/レプリカ（データベースによってはマスタ/スレーブとも呼ばれる）レプリケーションを使用した複数データベース構成をテストする場合、テスト用データベースを作成するこの方法には問題があります。テスト用データベースを作成すると、レプリケーションが行われなくなり、その結果、プライマリで作成されたデータがレプリカで見られなくなります。
\nこれを補うために、 Django ではデータベースを テストミラー と定義できます。以下の (単純化した) データベース設定例を見てください:
\nDATABASES = {\n "default": {\n "ENGINE": "django.db.backends.mysql",\n "NAME": "myproject",\n "HOST": "dbprimary",\n # ... plus some other settings\n },\n "replica": {\n "ENGINE": "django.db.backends.mysql",\n "NAME": "myproject",\n "HOST": "dbreplica",\n "TEST": {\n "MIRROR": "default",\n },\n # ... plus some other settings\n },\n}\nこの設定では、2つのデータベースサーバーがあります。 dbprimary はデータベースのエイリアス default で、 dbreplica はエイリアス replica で表します。期待の通り、 dbreplica はデータベース管理者によって dbprimary の読み込み用レプリカとして設定されているので、通常の操作では default への書き込みは replica に反映されます。
Django で2つの独立したテスト用データベースを作成した場合、レプリケーションを期待したテストが壊れてしまいます。しかし、 replica データベースはテスト用ミラーとして設定されており (テスト設定 MIRROR を使っています)、テストでは replica は default のミラーとして扱われるはずです。
テスト環境が設定されると、テストバージョンの replica は作成されません。代わりに replica への接続は default を指すようにリダイレクトされます。その結果、default への書き込みは replica に表示されますが、これは実際には同じデータベースであることが原因であり、2つのデータベース間でデータの複製が行われていることが原因ではありません。これはトランザクションに依存しているので、テストでは TestCase ではなく TransactionTestCase を使う必要があります。
デフォルトでは、 Django は全てのデータベースが default データベースに依存しているとみなすので、常に default データベースを最初に作成します。しかし、テストセットアップの他のデータベースの作成順は保証されません。
データベース構成が特定の作成順序を必要とする場合、DEPENDENCIES テスト設定を使用して存在する依存関係を指定できます。次の（単純化した）データベース構成の例を考えてみましょう:
DATABASES = {\n "default": {\n # ... db settings\n "TEST": {\n "DEPENDENCIES": ["diamonds"],\n },\n },\n "diamonds": {\n # ... db settings\n "TEST": {\n "DEPENDENCIES": [],\n },\n },\n "clubs": {\n # ... db settings\n "TEST": {\n "DEPENDENCIES": ["diamonds"],\n },\n },\n "spades": {\n # ... db settings\n "TEST": {\n "DEPENDENCIES": ["diamonds", "hearts"],\n },\n },\n "hearts": {\n # ... db settings\n "TEST": {\n "DEPENDENCIES": ["diamonds", "clubs"],\n },\n },\n}\nこの設定では、依存関係のない唯一のエイリアスである diamonds データベースが最初に作成されます。次に default と clubs のエイリアスが作成され（このペアの作成順序は保証されていません）、次に hearts が作成され、最後に spades が作成されます。
DEPENDENCIES の定義に循環依存がある場合、 ImproperlyConfigured 例外が発生します。
TransactionTestCase の高度な機能Link to this heading#デフォルトでは、available_apps は None に設定されています。各テスト後、Django は flush を呼び出して、データベースの状態をリセットします。これにより、すべてのテーブルが空になります。そして、post_migrate シグナルが送信されることにより、各モデルごとに、1つのコンテンツタイプと4つのパーミッションが再生成されます。この操作にかかるコストは、モデル数に比例して増大します。
available_apps にアプリケーションのリストを指定すると、 Django はこれらのアプリケーションのモデルだけが利用可能であるかのように動作します。 TransactionTestCase の動作は以下のように変わります:
post_migrate は、利用可能なアプリケーションの各モデルに対して、存在しない場合にコンテンツタイプやアクセス権を作成するために、各テストの前に起動します。
各テストの後、 Django は利用可能なアプリのモデルに対応するテーブルだけを空にします。しかし、データベースレベルでは、切り捨て（truncation）が利用できないアプリのリレーション先モデルにカスケードするかもしれません。さらに、 post_migrate は起動されません。正しいアプリケーションのセットが選択された後、次の TransactionTestCase で起動されます。
データベースは完全には flush されないので、テストが available_apps に含まれていないモデルのインスタンスを作成すると、そのインスタンスが漏れて無関係なテストが失敗する可能性があります。セッションを使用するテストには注意してください。デフォルトのセッションエンジンはセッションをデータベースに保存します。
データベースをフラッシュした後には post_migrate が発行されないため、TransactionTestCase の後の状態は TestCase の後の状態と同じではありません。つまり、post_migrate のリスナーによって作成された行が欠落しています。テストの実行順序に関する 注意事項 を踏まえると、与えられたテストスイート内のすべての TransactionTestCase が available_apps を宣言しているか、または一つも宣言していない場合、これは問題ではありません。
available_apps は Django 自身のテストスイートでは必須です。
TransactionTestCase で reset_sequences = True を設定すると、テスト実行前にシーケンスが常にリセットされます:
class TestsThatDependsOnPrimaryKeySequences(TransactionTestCase):\n reset_sequences = True\n\n def test_animal_pk(self):\n lion = Animal.objects.create(name="lion", sound="roar")\n # lion.pk is guaranteed to always be 1\n self.assertEqual(lion.pk, 1)\n主キーのシーケンス番号を明示的にテストするのでなければ、主キーの値をハードコーディングしないことを推奨します。
\n主キーのリセットは比較的高コストなデータベース操作なので、 reset_sequences = True を使用するとテストが遅くなります。
並列に実行できないテストクラスがある場合 (共通のリソースを共有している場合など)、 django.test.testcases.SerializeMixin を使って逐次実行できます。このミックスインはファイルシステムの lockfile を使用します。
たとえば、 __file__ を使用すると、同じファイルにある SerializeMixin を継承したすべてのテストクラスが順番に実行されるようにすることができます:
import os\n\nfrom django.test import TestCase\nfrom django.test.testcases import SerializeMixin\n\n\nclass ImageTestCaseMixin(SerializeMixin):\n lockfile = __file__\n\n def setUp(self):\n self.filename = os.path.join(temp_storage_dir, "my_file.png")\n self.file = create_file(self.filename)\n\n\nclass RemoveImageTests(ImageTestCaseMixin, TestCase):\n def test_remove_image(self):\n os.remove(self.filename)\n self.assertFalse(os.path.exists(self.filename))\n\n\nclass ResizeImageTests(ImageTestCaseMixin, TestCase):\n def test_resize_image(self):\n resize_image(self.file, (48, 48))\n self.assertEqual(get_image_size(self.file), (48, 48))\n再利用可能なアプリケーション を書いているのなら、 Django テストランナーを使って独自のテストスイートを実行し、Django のテスト基盤の恩恵を受けたいと思うかもしれません。
\n一般的な慣習は、アプリケーションコードの隣に tests ディレクトリを置き、以下のような構成にすることです:
\nruntests.py\npolls/\n __init__.py\n models.py\n ...\ntests/\n __init__.py\n models.py\n test_settings.py\n tests.py\nいくつかのファイルの中身を見てみましょう:
\nruntests.py#!/usr/bin/env python\nimport os\nimport sys\n\nimport django\nfrom django.conf import settings\nfrom django.test.utils import get_runner\n\nif __name__ == "__main__":\n os.environ["DJANGO_SETTINGS_MODULE"] = "tests.test_settings"\n django.setup()\n TestRunner = get_runner(settings)\n test_runner = TestRunner()\n failures = test_runner.run_tests(["tests"])\n sys.exit(bool(failures))\nこれはテストスイートを実行するために呼び出すスクリプトです。Django 環境をセットアップし、テストデータベースを作成し、テストを実行します。
\nわかりやすくするために、この例では Django テストランナーを使うために必要な最低限のものだけを含んでいます。冗長性を制御したり、実行する特定のテストラベルを渡したりするためのコマンドラインオプションを追加しても構いません。
\ntests/test_settings.pySECRET_KEY = "fake-key"\nINSTALLED_APPS = [\n "tests",\n]\nこのファイルには、アプリのテストを実行するために必要な Django の設定 が含まれています。
\n繰り返しますが、これは最小限の例です。テストを実行するには、さらに別の設定が必要になるかもしれません。
\ntests パッケージはテストを実行する際に INSTALLED_APPS に含まれるので、その models.py ファイルにテスト専用のモデルを定義することもできます。
明らかに、unittest は唯一のPythonテストフレームワークではありません。Djangoは代替フレームワークに対する明示的なサポートを提供していませんが、代替フレームワーク向けに構築されたテストを通常のDjangoテストのように呼び出す方法に対応しています。
./manage.py test を実行するとき、Django は TEST_RUNNER 設定を見て、何をするかを決定します。デフォルトでは、 TEST_RUNNER は 'django.test.runner.DiscoverRunner' を指します。このクラスは Django のデフォルトのテスト動作を定義します。この動作には下記が含まれます:
テスト前のグローバルなセットアップの実行。
現在のディレクトリ以下のファイルの中から、名前が test*.py と一致するテストを探す。
テストデータベースの作成。
テストデータベースにモデルと初期データをインストールするために migrate を実行する。
システムチェック の実行。
見つかったテストを実行する。
テストデータベースの破棄。
テスト後のグローバルな後処理の実行。
独自のテストランナークラスを定義し、 TEST_RUNNER をそのクラスに向けると、 Django は常に ./manage.py test を実行するときに、あなたのテストランナを実行します。この方法なら、 Python コードから実行できるテストフレームワークを使ったり、 Django のテスト実行プロセスを変更して、どんなテスト要件でも満たすことができます。
テストランナーは run_tests() メソッドを定義したクラスです。Django には、デフォルトの Django のテスト動作を定義する DiscoverRunner クラスが同梱されています。このクラスは run_tests() のエントリーポイントを定義し、さらに run_tests() がテストスイートのセットアップ、実行、終了に使用する他のメソッドも定義します。
DiscoverRunner は pattern にマッチするファイル内のテストを検索します。
top_level を使うと、トップレベルの Python モジュールを含むディレクトリを指定できます。通常、 Django はこれを自動的に判別するので、このオプションを指定する必要はありません。もし指定するなら、通常は manage.py ファイルがあるディレクトリを指定します。
verbosity はコンソールに出力される通知とデバッグ情報の量を決定します。 0 は出力なし、 1 は通常の出力、 2 は冗長 (verbose) な出力です。
interactive が True の場合、テストスイートが実行されるときにユーザーに指示を求める権限があります。この動作の例は、既存のテストデータベースを削除する許可を求めるようなものです。もし interactive が False なら、テストスイートは手動で操作しなくても実行できる必要があります。
failfast が True の場合、テストスイートは最初のテストの失敗を検出した後に実行を停止します。
keepdb が True の場合、テストスイートは既存のデータベースを使用します。 False の場合は、新しいデータベースを作成し、既存のデータベースを削除するようユーザに促します。
reverse が True の場合、テストケースは逆の順番で実行されます。これは適切に分離されておらず、副作用があるテストをデバッグするのに便利です。 テストクラス によるグループ化は、このオプションを使用しても保持されます。このオプションは --shuffle と組み合わせて、特定のランダムシードの順序を逆にするために使用できます。
debug_mode は、テストを実行する前に DEBUG 設定を何に設定するべきかを指定します。
parallel はプロセス数を指定します。 parallel が 1 より大きい場合、テストスイートは parallel プロセスで実行されます。指定されたプロセス数よりもテストケースクラスの数が少ない場合、 Django はそれに応じてプロセス数を減らします。各プロセスは独自のデータベースを取得します。このオプションでは、トレースバックを正しく表示するためにサードパーティの tblib パッケージが必要です。
tags は テストをフィルタリングするタグ に使用できます。 exclude_tags と併用できます。
exclude_tags は、テストを除外するための タグのセット の指定に使用できます。 tags と併用できます。
debug_sql が True の場合、失敗したテストケースはトレースバックと同様に django.db.backends のロガー に記録された SQL クエリを出力します。もし verbosity が 2 なら、すべてのテストのクエリが出力されます。
test_name_patterns を使うと、テストメソッドやクラスを名前でフィルタするためのパターンセットを指定できます。
pdb が True の場合、デバッガ (pdb または ipdb) がテストのエラーや失敗のたびに起動されます。
buffer が True の場合、合格したテストの出力は破棄されます。
enable_faulthandler が True の場合、 faulthandler が有効になります。
timing が True の場合、データベースのセットアップと総実行時間を含むテスト時間が表示されます。
shuffle が整数の場合、その整数はランダムシードとして使用され、テストケースが実行前にランダムな順序でシャッフルされます。 shuffle が None の場合、シードはランダムに生成されます。どちらの場合も、シードはテスト実行前に記録され、 self.shuffle_seed に設定されます。このオプションは、適切に分離されていないテストを検出するのに役立つことがあります。このオプションを使用する場合、 テストクラスによるグルーピング が保持されます。
logger は Python Logger オブジェクト を渡すために使用します。指定された場合、ロガーはコンソールに出力する代わりにログメッセージを記録します。ロガーオブジェクトは verbosity よりもロギングレベルを優先します。
durations を指定すると、最も遅い N 個のテストケースのリストが表示されます。このオプションに 0 を指定すると、すべてのテストの所要時間が表示されます。Python 3.12+ が必要です。
Django では、新しい引数を追加することで、テストランナーの機能を拡張するこ とがあります。この拡張を可能にするのが **kwargs 宣言です。もし DiscoverRunner をサブクラス化したり、独自のテストランナーを書いたりする場合は、 **kwargs を受け付けるようにしてください。
テストランナーでは、追加のコマンドラインオプションを定義することもできます。 add_arguments(cls, parser) クラスメソッドを作成またはオーバーライドし、そのメソッド内で parser.add_argument() を呼び出すときにカスタム引数を追加することで、 test コマンドがそれらの引数を使用できるようになります。
テストスイートのビルドに使用するクラス。デフォルトでは unittest.TestSuite に設定されています。テストを収集するために別のロジックを実装したい場合は、これをオーバーライドできます。
これは低レベルテストランナーのクラスで、個々のテストを実行し、結果をフォーマットするために使用されます。デフォルトでは unittest.TextTestRunner に設定されています。似たような名前になっていますが、残念ながらこれは DiscoverRunner と同じ種類のクラスではありません。この属性をオーバーライドすることで、テストの実行方法やレポート方法を変更できます。
これは、TestCases やモジュールなどからテストを読み込んで、ランナーが実行するテストスイートにバンドルするクラスです。デフォルトでは unittest.defaultTestLoader に設定されています。通常とは異なる方法でテストを読み込む場合は、この属性をオーバーライドします。
テストスイートを実行します。
\ntest_labels は実行するテストを指定するもので、いくつかのフォーマットをサポートしています (サポートされているフォーマットのリストについては DiscoverRunner.build_suite() を参照してください)。
このメソッドは、失敗したテストの数を返す必要があります。
\nこのクラスメソッドをオーバーライドして test 管理コマンドが受け付けるカスタム引数を追加できます。パーサへの引数の追加についての詳細は argparse.ArgumentParser.add_argument() を参照してください。
setup_test_environment() を呼び出して、 DEBUG を self.debug_mode (デフォルトは False) に設定することで、テスト環境をセットアップできます。
指定されたテストラベルにマッチするテストスイートを構築（コンストラクト）します。
\ntest_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 (上記参照) にマッチする名前のテストを探します。
実行可能な TestSuite インスタンスを返します。
setup_databases() を呼び出して、テスト用データベースを作成します。
システムチェック をテスト用の databases に対して実行します。
テストスイートを実行します。
\nテストスイートの実行結果を返します。
\nDiscoverRunner.test_runner をインスタンス化するためのキーワード引数を返します。
teardown_databases() を呼び出すことで、テストデータベースを破棄し、テスト前の状態に戻します。
テスト前の環境を復元します。
\nテストスイートを基にリターンコードを計算し、その結果を返します。
\nもし logger が設定されている場合、与えられた整数の logging level (例えば logging.DEBUG, logging.INFO または logging.WARNING) でメッセージをログに記録します。そうでない場合は、現在の verbosity に従ってコンソールにメッセージが出力されます。例えば、 verbosity が 0 の場合はメッセージは表示されず、 verbosity が 1 以上の場合は INFO 以上のメッセージが表示され、2 以上の場合は DEBUG のメッセージが表示されます。 level のデフォルトは logging.INFO です。
django.test.utilsLink to this heading#独自のテストランナーの作成を支援するために、Django は django.test.utils モジュールで多くのユーティリティメソッドを提供しています。
グローバルな前処理テストセットアップを実行します。これには、テンプレートレンダリングシステム用の計測ツールのインストールや、ダミーのメールアウトボックスのセットアップが含まれます。
\ndebug が None 以外の場合、 DEBUG 設定はその値に更新されます。
グローバルな後処理テストのテアダウン（解体）を実行します。これには、テンプレートシステムから計測ツールを削除し、通常のメールサービスを復元することが含まれます。
\nテスト用データベースを作成します。
\n行われた変更を元に戻すのに十分な詳細情報を提供するデータ構造を返します。このデータはテスト終了時に teardown_databases() 関数に渡されます。
引数 aliases はどの DATABASES エイリアスにテスト用データベースを設定するかを決定します。省略された場合、デフォルトは DATABASES の全てのエイリアスです。
serialized_aliases 引数は、 aliases テストデータベースのどのサブセットがその状態をシリアライズすべきかを特定し、 serialized_rollback 機能が利用できるようにします。指定しなかった場合、デフォルトは aliases になります。
テスト データベースを破棄し、テスト前の状態に戻します。
\nold_config は元に戻すべきデータベース設定の変更を定義したデータ構造です。これは setup_databases() メソッドの戻り値です。
django.db.connection.creationLink to this heading#データベースバックエンドの作成モジュールは、テスト中に役立つユーティリティも提供しています。
\n新しいテストデータベースを作成し、それに対して migrate を実行します。
verbosity は run_tests() と同じ動作です。
autoclobber はテストデータベースと同じ名前のデータベースを見つけた場合の動作を表します:
autoclobber が False の場合、ユーザは既存のデータベースを破棄することを承認するよう求められます。ユーザーが承認しない場合は sys.exit が呼び出されます。
autoclobber が True の場合、ユーザーに通知することなくデータベースを破棄します。
serialize は、テストを実行する前に、Django がデータベースをメモリ内の JSON 文字列にシリアライズするかどうかを決定します (トランザクションがない場合、テスト間でデータベースの状態を復元するために使います)。これを False に設定すると、 serialized_rollback=True を持つテストクラスがない場合に、作成時間を短縮できます。
keepdb はテスト実行時に既存のデータベースを使用するか、新しいデータベースを作成するかを決定します。もし True なら、既存のデータベースが使用され、存在しない場合は作成されます。もし False ならば、新しいデータベースが作成され、既存のデータベースを削除するようにユーザに促します。
作成したテスト用データベースの名前を返します。
\ncreate_test_db() は DATABASES の NAME の値をテストデータベースの名前と一致するように変更するという副作用があります。
DATABASES の NAME の値を名前とするデータベースを破棄し、 NAME に old_database_name の値をセットします。
verbosity 引数は DiscoverRunner と同じ動作です。
keepdb 引数が True の場合、データベースへの接続は閉じられますが、データベースは破棄されません。
データベースの内容をメモリ上の JSON 文字列としてシリアライズします。これは、使用しているバックエンドがトランザクションをサポートしていない場合や、テストスイートに serialized_rollback=True を有効にしたテストクラスが含まれている場合に、テスト間でデータベースの状態を復元するために使用されます。
\nこの関数は、すべてのテスト用データベースが作成された後にのみ呼び出すべきです。シリアライズ処理中に、 ルーティングの設定 によってテスト用でないデータベースに対してクエリが発行される可能性があるためです。
\ncoverage.py との統合Link to this heading#コードカバレッジは、ソースコードがどれだけテストされたかを表します。コードカバレッジは、コードのどの部分がテストで実施され、 どの部分が実施されていないのかを表します。アプリケーションをテストする上で重要な要素なので、テストのカバレッジをチェックすることを強く推奨します。
\nDjango は Python プログラムのコードカバレッジを測定するツール coverage.py と簡単に統合できます。まず、 coverage をインストールします。次に、 manage.py を含むプロジェクトフォルダから以下を実行してください:
coverage run --source='.' manage.py test myapp\nこれはテストを実行し、プロジェクト内で実行されたファイルのカバレッジデータを収集します。次のコマンドを入力すると、このデータのレポートを見ることができます:
\ncoverage report\nテストの実行中に、いくつかの Django コードが実行されましたが、前のコマンドに source フラグが渡されたため、ここには記載されていないことに注意してください。
テストに失敗した行の詳細を注釈を付けてHTMLに表示するなどのオプションについては、 coverage.py のドキュメントを参照してください。
\n