--- title: "テストに関する高度なトピック" version: 6.1 locale: ja source: https://docs.djangoproject.com/ja/6.1/topics/testing/advanced/ canonical: https://djangodocs.dev/ja/6.1/topics/testing/advanced/ --- # テストに関する高度なトピック ## RequestFactory（リクエスト ファクトリ） #### `class RequestFactory` [`RequestFactory`](#django.test.RequestFactory) はテストクライアントと同じ API を共有しています。しかし、ブラウザのように動作するのではなく、 RequestFactory は任意のビューの最初の引数として使用できるリクエストインスタンスを生成する方法を提供します。つまり、ビュー関数を他の関数をテストするのと同じ方法で テストできます。入力が完全にわかっているブラックボックスとして、特定の出力をテストできます。 [`RequestFactory`](#django.test.RequestFactory) の API は、テストクライアント API の少し制限されたサブセットです: - It only has access to the HTTP methods [`get()`](/ja/6.1/topics/testing/tools/#django.test.Client.get), [`post()`](/ja/6.1/topics/testing/tools/#django.test.Client.post), [`put()`](/ja/6.1/topics/testing/tools/#django.test.Client.put), [`delete()`](/ja/6.1/topics/testing/tools/#django.test.Client.delete), [`head()`](/ja/6.1/topics/testing/tools/#django.test.Client.head), [`options()`](/ja/6.1/topics/testing/tools/#django.test.Client.options), and [`trace()`](/ja/6.1/topics/testing/tools/#django.test.Client.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 #### `class AsyncRequestFactory` `RequestFactory` は WSGI ライクなリクエストを作成します。正しい ASGI `scope` を持つなど、ASGI ライクなリクエストを作成したい場合は、代わりに `django.test.AsyncRequestFactory` が使用できます。 このクラスは `RequestFactory` と直接 API 互換ですが、唯一の違いは `WSGIRequest` インスタンスではなく `ASGIRequest` インスタンスを返すことです。そのメソッドはすべて同期呼び出し可能オブジェクトのままです。 `defaults` 内の任意のキーワード引数は直接ASGIスコープに追加されます。 ## クラスベースのビューをテストする リクエスト/レスポンスサイクルの外でクラスベースのビューをテストするには、インスタンス化後に [`setup()`](/ja/6.1/ref/class-based-views/base/#django.views.generic.base.View.setup) を呼び出して、正しく設定されていることを確認する必要があります。 たとえば、以下のようなクラスベースのビューを想定します: *`views.py`* ```python 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()` メソッドを直接テストするには、まずビューをインスタンス化して `setup()` に `request` を渡します: *`tests.py`* ```python 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`](/ja/6.1/ref/settings/#std-setting-ALLOWED_HOSTS) 設定はテストを実行する際に検証されます。これによりテストクライアントが内部 URL と外部 URL を区別できるようになります。 マルチテナントをサポートするプロジェクトや、リクエストのホストに基づいてビジネスロジックを変更するプロジェクトで、カスタムホスト名をテストで使用する場合は、それらのホストを [`ALLOWED_HOSTS`](/ja/6.1/ref/settings/#std-setting-ALLOWED_HOSTS) に含める必要があります。 そのための最初の選択肢は、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", ...] ``` Another option is to add the required hosts to [`ALLOWED_HOSTS`](/ja/6.1/ref/settings/#std-setting-ALLOWED_HOSTS) using [`override_settings()`](/ja/6.1/topics/testing/tools/#django.test.override_settings) or [`modify_settings`](/ja/6.1/topics/testing/tools/#django.test.SimpleTestCase.modify_settings). This option may be preferable in standalone apps that can't package their own settings file or for projects where the list of domains is not static (e.g., subdomains for multitenancy). For example, you could write a test for the domain `http://otherserver/` as follows: ``` 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`](/ja/6.1/ref/settings/#std-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つのデータベースサーバーがあります。 `dbprimary` はデータベースのエイリアス `default` で、 `dbreplica` はエイリアス `replica` で表します。期待の通り、 `dbreplica` はデータベース管理者によって `dbprimary` の読み込み用レプリカとして設定されているので、通常の操作では `default` への書き込みは `replica` に反映されます。 Django で2つの独立したテスト用データベースを作成した場合、レプリケーションを期待したテストが壊れてしまいます。しかし、 `replica` データベースはテスト用ミラーとして設定されており (テスト設定 [`MIRROR`](/ja/6.1/ref/settings/#std-setting-TEST_MIRROR) を使っています)、テストでは `replica` は `default` のミラーとして扱われるはずです。 テスト環境が設定されると、テストバージョンの `replica` は作成されません。代わりに `replica` への接続は `default` を指すようにリダイレクトされます。その結果、`default` への書き込みは `replica` に表示されますが、これは実際には同じデータベースであることが原因であり、2つのデータベース間でデータの複製が行われていることが原因ではありません。これはトランザクションに依存しているので、テストでは [`TestCase`](/ja/6.1/topics/testing/tools/#django.test.TestCase) ではなく [`TransactionTestCase`](/ja/6.1/topics/testing/tools/#django.test.TransactionTestCase) を使う必要があります。 ### テストデータベースの作成順をコントロールする デフォルトでは、 Django は全てのデータベースが `default` データベースに依存しているとみなすので、常に `default` データベースを最初に作成します。しかし、テストセットアップの他のデータベースの作成順は保証されません。 データベース構成が特定の作成順序を必要とする場合、[`DEPENDENCIES`](/ja/6.1/ref/settings/#std-setting-TEST_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` が作成されます。 [`DEPENDENCIES`](/ja/6.1/ref/settings/#std-setting-TEST_DEPENDENCIES) の定義に循環依存がある場合、 [`ImproperlyConfigured`](/ja/6.1/ref/exceptions/#django.core.exceptions.ImproperlyConfigured) 例外が発生します。 ## `TransactionTestCase` の高度な機能 #### `TransactionTestCase.available_apps` > **Warning** > > この属性はプライベートAPIです。例えば、アプリケーションの読み込みの変更に対応するために、将来、非推奨期間なしに変更または削除される可能性があります。 > > これは Django 自身のテストスイートを最適化するために使われます。このテストスイート には何百ものモデルが含まれますが、異なるアプリケーションのモデル間のリレーションはありません。 デフォルトでは、`available_apps` は `None` に設定されています。各テスト後、Django は [`flush`](/ja/6.1/ref/django-admin/#django-admin-flush) を呼び出して、データベースの状態をリセットします。これにより、すべてのテーブルが空になります。そして、[`post_migrate`](/ja/6.1/ref/signals/#django.db.models.signals.post_migrate) シグナルが送信されることにより、各モデルごとに、1つのコンテンツタイプと4つのパーミッションが再生成されます。この操作にかかるコストは、モデル数に比例して増大します。 `available_apps` にアプリケーションのリストを指定すると、 Django はこれらのアプリケーションのモデルだけが利用可能であるかのように動作します。 `TransactionTestCase` の動作は以下のように変わります: - [`post_migrate`](/ja/6.1/ref/signals/#django.db.models.signals.post_migrate) は、利用可能なアプリケーションの各モデルに対して、存在しない場合にコンテンツタイプやアクセス権を作成するために、各テストの前に起動します。 - 各テストの後、 Django は利用可能なアプリのモデルに対応するテーブルだけを空にします。しかし、データベースレベルでは、切り捨て（truncation）が利用できないアプリのリレーション先モデルにカスケードするかもしれません。さらに、 [`post_migrate`](/ja/6.1/ref/signals/#django.db.models.signals.post_migrate) は起動されません。正しいアプリケーションのセットが選択された後、次の `TransactionTestCase` で起動されます。 データベースは完全には flush されないので、テストが `available_apps` に含まれていないモデルのインスタンスを作成すると、そのインスタンスが漏れて無関係なテストが失敗する可能性があります。セッションを使用するテストには注意してください。デフォルトのセッションエンジンはセッションをデータベースに保存します。 データベースをフラッシュした後には [`post_migrate`](/ja/6.1/ref/signals/#django.db.models.signals.post_migrate) が発行されないため、`TransactionTestCase` の後の状態は `TestCase` の後の状態と同じではありません。つまり、[`post_migrate`](/ja/6.1/ref/signals/#django.db.models.signals.post_migrate) のリスナーによって作成された行が欠落しています。テストの実行順序に関する [注意事項](/ja/6.1/topics/testing/overview/#order-of-tests) を踏まえると、与えられたテストスイート内のすべての `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) ``` Unless you are explicitly testing primary keys sequence numbers, it is recommended that you do not hardcode primary key values in tests. 主キーのリセットは比較的高コストなデータベース操作なので、 `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 テストランナーを使って再利用可能なアプリケーションをテストする [再利用可能なアプリケーション](/ja/6.1/intro/reusable-apps/) を書いているのなら、 Django テストランナーを使って独自のテストスイートを実行し、Django のテスト基盤の恩恵を受けたいと思うかもしれません。 一般的な慣習は、アプリケーションコードの隣に *tests* ディレクトリを置き、以下のような構成にすることです: ```text runtests.py polls/ __init__.py models.py ... tests/ __init__.py models.py test_settings.py tests.py ``` いくつかのファイルの中身を見てみましょう: *`runtests.py`* ```python #!/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`* ```python SECRET_KEY = "fake-key" INSTALLED_APPS = [ "tests", ] ``` このファイルには、アプリのテストを実行するために必要な [Django の設定](/ja/6.1/topics/settings/) が含まれています。 繰り返しますが、これは最小限の例です。テストを実行するには、さらに別の設定が必要になるかもしれません。 *tests* パッケージはテストを実行する際に [`INSTALLED_APPS`](/ja/6.1/ref/settings/#std-setting-INSTALLED_APPS) に含まれるので、その `models.py` ファイルにテスト専用のモデルを定義することもできます。 ## ほかのテストフレームワークを使う 明らかに、[`unittest`](https://docs.python.org/3/library/unittest.html#module-unittest) は唯一のPythonテストフレームワークではありません。Djangoは代替フレームワークに対する明示的なサポートを提供していませんが、代替フレームワーク向けに構築されたテストを通常のDjangoテストのように呼び出す方法に対応しています。 `./manage.py test` を実行するとき、Django は [`TEST_RUNNER`](/ja/6.1/ref/settings/#std-setting-TEST_RUNNER) 設定を見て、何をするかを決定します。デフォルトでは、 [`TEST_RUNNER`](/ja/6.1/ref/settings/#std-setting-TEST_RUNNER) は `'django.test.runner.DiscoverRunner'` を指します。このクラスは Django のデフォルトのテスト動作を定義します。この動作には下記が含まれます: 1. テスト前のグローバルなセットアップの実行。 2. 現在のディレクトリ以下のファイルの中から、名前が `test*.py` と一致するテストを探す。 3. テストデータベースの作成。 4. テストデータベースにモデルと初期データをインストールするために `migrate` を実行する。 5. [システムチェック](/ja/6.1/topics/checks/) の実行。 6. 見つかったテストを実行する。 7. テストデータベースの破棄。 8. テスト後のグローバルな後処理の実行。 独自のテストランナークラスを定義し、 [`TEST_RUNNER`](/ja/6.1/ref/settings/#std-setting-TEST_RUNNER) をそのクラスに向けると、 Django は常に `./manage.py test` を実行するときに、あなたのテストランナを実行します。この方法なら、 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, shuffle=False, logger=None, durations=None, **kwargs)` `DiscoverRunner` は `pattern` にマッチするファイル内のテストを検索します。 `top_level` を使うと、トップレベルの Python モジュールを含むディレクトリを指定できます。通常、 Django はこれを自動的に判別するので、このオプションを指定する必要はありません。もし指定するなら、通常は `manage.py` ファイルがあるディレクトリを指定します。 `verbosity` はコンソールに出力される通知とデバッグ情報の量を決定します。 `0` は出力なし、 `1` は通常の出力、 `2` は冗長 (verbose) な出力です。 `interactive` が `True` の場合、テストスイートが実行されるときにユーザーに指示を求める権限があります。この動作の例は、既存のテストデータベースを削除する許可を求めるようなものです。もし `interactive` が `False` なら、テストスイートは手動で操作しなくても実行できる必要があります。 `failfast` が `True` の場合、テストスイートは最初のテストの失敗を検出した後に実行を停止します。 `keepdb` が `True` の場合、テストスイートは既存のデータベースを使用します。 `False` の場合は、新しいデータベースを作成し、既存のデータベースを削除するようユーザに促します。 `reverse` が `True` の場合、テストケースは逆の順番で実行されます。これは適切に分離されておらず、副作用があるテストをデバッグするのに便利です。 [テストクラス](/ja/6.1/topics/testing/overview/#order-of-tests) によるグループ化は、このオプションを使用しても保持されます。このオプションは `--shuffle` と組み合わせて、特定のランダムシードの順序を逆にするために使用できます。 `debug_mode` は、テストを実行する前に [`DEBUG`](/ja/6.1/ref/settings/#std-setting-DEBUG) 設定を何に設定するべきかを指定します。 `parallel` specifies the number of processes. If `parallel` is greater than `1`, the test suite will run in `parallel` processes. If there are fewer test case classes than configured processes, Django will reduce the number of processes accordingly. Each process gets its own database. This option requires the third-party `tblib` package to display tracebacks correctly. `tags` は [テストをフィルタリングするタグ](/ja/6.1/topics/testing/tools/#topics-tagging-tests) に使用できます。 `exclude_tags` と併用できます。 `exclude_tags` は、テストを除外するための [タグのセット](/ja/6.1/topics/testing/tools/#topics-tagging-tests) の指定に使用できます。 `tags` と併用できます。 `debug_sql` が `True` の場合、失敗したテストケースはトレースバックと同様に [django.db.backends のロガー](/ja/6.1/ref/logging/#django-db-logger) に記録された SQL クエリを出力します。もし `verbosity` が `2` なら、すべてのテストのクエリが出力されます。 `test_name_patterns` を使うと、テストメソッドやクラスを名前でフィルタするためのパターンセットを指定できます。 `pdb` が `True` の場合、デバッガ (`pdb` または `ipdb`) がテストのエラーや失敗のたびに起動されます。 `buffer` が `True` の場合、合格したテストの出力は破棄されます。 If `enable_faulthandler` is `True`, [`faulthandler`](https://docs.python.org/3/library/faulthandler.html#module-faulthandler) will be enabled. `timing` が `True` の場合、データベースのセットアップと総実行時間を含むテスト時間が表示されます。 `shuffle` が整数の場合、その整数はランダムシードとして使用され、テストケースが実行前にランダムな順序でシャッフルされます。 `shuffle` が `None` の場合、シードはランダムに生成されます。どちらの場合も、シードはテスト実行前に記録され、 `self.shuffle_seed` に設定されます。このオプションは、適切に分離されていないテストを検出するのに役立つことがあります。このオプションを使用する場合、 [テストクラスによるグルーピング](/ja/6.1/topics/testing/overview/#order-of-tests) が保持されます。 `logger` can be used to pass a Python [Logger object](https://docs.python.org/3/library/logging.html#logger). If provided, the logger will be used to log messages instead of printing to the console. The logger object will respect its logging level rather than the `verbosity`. `durations` will show a list of the N slowest test cases. Setting this option to `0` will result in the duration for all tests being shown. Django では、新しい引数を追加することで、テストランナーの機能を拡張するこ とがあります。この拡張を可能にするのが `**kwargs` 宣言です。もし `DiscoverRunner` をサブクラス化したり、独自のテストランナーを書いたりする場合は、 `**kwargs` を受け付けるようにしてください。 テストランナーでは、追加のコマンドラインオプションを定義することもできます。 `add_arguments(cls, parser)` クラスメソッドを作成またはオーバーライドし、そのメソッド内で `parser.add_argument()` を呼び出すときにカスタム引数を追加することで、 [`test`](/ja/6.1/ref/django-admin/#django-admin-test) コマンドがそれらの引数を使用できるようになります。 #### 属性 #### `DiscoverRunner.test_suite` テストスイートのビルドに使用するクラス。デフォルトでは `unittest.TestSuite` に設定されています。テストを収集するために別のロジックを実装したい場合は、これをオーバーライドできます。 #### `DiscoverRunner.test_runner` これは低レベルテストランナーのクラスで、個々のテストを実行し、結果をフォーマットするために使用されます。デフォルトでは `unittest.TextTestRunner` に設定されています。似たような名前になっていますが、残念ながらこれは `DiscoverRunner` と同じ種類のクラスではありません。この属性をオーバーライドすることで、テストの実行方法やレポート方法を変更できます。 #### `DiscoverRunner.test_loader` これは、TestCases やモジュールなどからテストを読み込んで、ランナーが実行するテストスイートにバンドルするクラスです。デフォルトでは `unittest.defaultTestLoader` に設定されています。通常とは異なる方法でテストを読み込む場合は、この属性をオーバーライドします。 #### メソッド #### `DiscoverRunner.run_tests(test_labels, **kwargs)` テストスイートを実行します。 `test_labels` は実行するテストを指定するもので、いくつかのフォーマットをサポートしています (サポートされているフォーマットのリストについては [`DiscoverRunner.build_suite()`](#django.test.runner.DiscoverRunner.build_suite) を参照してください)。 このメソッドは、失敗したテストの数を返す必要があります。 #### `classmethod DiscoverRunner.add_arguments(parser)` Override this class method to add custom arguments accepted by the [`test`](/ja/6.1/ref/django-admin/#django-admin-test) management command. See [`argparse.ArgumentParser.add_argument()`](https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_argument) for details about adding arguments to a parser. #### `DiscoverRunner.setup_test_environment(**kwargs)` [`setup_test_environment()`](#django.test.utils.setup_test_environment) を呼び出して、 [`DEBUG`](/ja/6.1/ref/settings/#std-setting-DEBUG) を `self.debug_mode` (デフォルトは `False`) に設定することで、テスト環境をセットアップできます。 #### `DiscoverRunner.build_suite(test_labels=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` (上記参照) にマッチする名前のテストを探します。 実行可能な `TestSuite` インスタンスを返します。 #### `DiscoverRunner.setup_databases(**kwargs)` [`setup_databases()`](#django.test.utils.setup_databases) を呼び出して、テスト用データベースを作成します。 #### `DiscoverRunner.run_checks(databases)` [システムチェック](/ja/6.1/topics/checks/) をテスト用の `databases` に対して実行します。 #### `DiscoverRunner.run_suite(suite, **kwargs)` テストスイートを実行します。 テストスイートの実行結果を返します。 #### `DiscoverRunner.get_test_runner_kwargs()` `DiscoverRunner.test_runner` をインスタンス化するためのキーワード引数を返します。 #### `DiscoverRunner.teardown_databases(old_config, **kwargs)` [`teardown_databases()`](#django.test.utils.teardown_databases) を呼び出すことで、テストデータベースを破棄し、テスト前の状態に戻します。 #### `DiscoverRunner.teardown_test_environment(**kwargs)` テスト前の環境を復元します。 #### `DiscoverRunner.suite_result(suite, result, **kwargs)` テストスイートを基にリターンコードを計算し、その結果を返します。 #### `DiscoverRunner.log(msg, level=None)` もし `logger` が設定されている場合、与えられた整数の [logging level](https://docs.python.org/3/library/logging.html#levels) (例えば `logging.DEBUG`, `logging.INFO` または `logging.WARNING`) でメッセージをログに記録します。そうでない場合は、現在の `verbosity` に従ってコンソールにメッセージが出力されます。例えば、 `verbosity` が 0 の場合はメッセージは表示されず、 `verbosity` が 1 以上の場合は `INFO` 以上のメッセージが表示され、2 以上の場合は `DEBUG` のメッセージが表示されます。 `level` のデフォルトは `logging.INFO` です。 ### テスト用ユーティリティ #### `django.test.utils` 独自のテストランナーの作成を支援するために、Django は `django.test.utils` モジュールで多くのユーティリティメソッドを提供しています。 #### `setup_test_environment(debug=None)` グローバルな前処理テストセットアップを実行します。これには、テンプレートレンダリングシステム用の計測ツールのインストールや、ダミーのメールアウトボックスのセットアップが含まれます。 `debug` が `None` 以外の場合、 [`DEBUG`](/ja/6.1/ref/settings/#std-setting-DEBUG) 設定はその値に更新されます。 #### `teardown_test_environment()` グローバルな後処理テストのテアダウン（解体）を実行します。これには、テンプレートシステムから計測ツールを削除し、通常のメールサービスを復元することが含まれます。 #### `setup_databases(verbosity, interactive, * (Keyword-only parameters separator (PEP 3102)), time_keeper=None, keepdb=False, debug_sql=False, parallel=0, aliases=None, serialized_aliases=None, **kwargs)` テスト用データベースを作成します。 行われた変更を元に戻すのに十分な詳細情報を提供するデータ構造を返します。このデータはテスト終了時に [`teardown_databases()`](#django.test.utils.teardown_databases) 関数に渡されます。 引数 `aliases` はどの [`DATABASES`](/ja/6.1/ref/settings/#std-setting-DATABASES) エイリアスにテスト用データベースを設定するかを決定します。省略された場合、デフォルトは [`DATABASES`](/ja/6.1/ref/settings/#std-setting-DATABASES) の全てのエイリアスです。 `serialized_aliases` 引数は、 `aliases` テストデータベースのどのサブセットがその状態をシリアライズすべきかを特定し、 [serialized\_rollback](/ja/6.1/topics/testing/overview/#test-case-serialized-rollback) 機能が利用できるようにします。指定しなかった場合、デフォルトは `aliases` になります。 #### `teardown_databases(old_config, parallel=0, keepdb=False)` テスト データベースを破棄し、テスト前の状態に戻します。 `old_config` は元に戻すべきデータベース設定の変更を定義したデータ構造です。これは [`setup_databases()`](#django.test.utils.setup_databases) メソッドの戻り値です。 #### `django.db.connection.creation` データベースバックエンドの作成モジュールは、テスト中に役立つユーティリティも提供しています。 #### `create_test_db(verbosity=1, autoclobber=False, keepdb=False)` 新しいテストデータベースを作成し、それに対して `migrate` を実行します。 `verbosity` は `run_tests()` と同じ動作です。 `autoclobber` はテストデータベースと同じ名前のデータベースを見つけた場合の動作を表します: - `autoclobber` が `False` の場合、ユーザは既存のデータベースを破棄することを承認するよう求められます。ユーザーが承認しない場合は `sys.exit` が呼び出されます。 - `autoclobber` が `True` の場合、ユーザーに通知することなくデータベースを破棄します。 `keepdb` はテスト実行時に既存のデータベースを使用するか、新しいデータベースを作成するかを決定します。もし `True` なら、既存のデータベースが使用され、存在しない場合は作成されます。もし `False` ならば、新しいデータベースが作成され、既存のデータベースを削除するようにユーザに促します。 作成したテスト用データベースの名前を返します。 `create_test_db()` は [`DATABASES`](/ja/6.1/ref/settings/#std-setting-DATABASES) の [`NAME`](/ja/6.1/ref/settings/#std-setting-NAME) の値をテストデータベースの名前と一致するように変更するという副作用があります。 > **Deprecated since Django 6.0** > > バージョン 6.0 で非推奨: The `serialize` keyword argument is deprecated. Passing > `serialize=True` would automatically call > [`serialize_db_to_string()`](#django.db.connection.creation.serialize_db_to_string) but it was deprecated as it could result > in queries against non-test databases during serialization. #### `destroy_test_db(old_database_name, verbosity=1, keepdb=False)` [`DATABASES`](/ja/6.1/ref/settings/#std-setting-DATABASES) の [`NAME`](/ja/6.1/ref/settings/#std-setting-NAME) の値を名前とするデータベースを破棄し、 [`NAME`](/ja/6.1/ref/settings/#std-setting-NAME) に `old_database_name` の値をセットします。 `verbosity` 引数は [`DiscoverRunner`](#django.test.runner.DiscoverRunner) と同じ動作です。 `keepdb` 引数が `True` の場合、データベースへの接続は閉じられますが、データベースは破棄されません。 #### `serialize_db_to_string()` データベースの内容をメモリ上の JSON 文字列としてシリアライズします。これは、使用しているバックエンドがトランザクションをサポートしていない場合や、テストスイートに [serialized\_rollback=True](/ja/6.1/topics/testing/overview/#test-case-serialized-rollback) を有効にしたテストクラスが含まれている場合に、テスト間でデータベースの状態を復元するために使用されます。 この関数は、すべてのテスト用データベースが作成された後にのみ呼び出すべきです。シリアライズ処理中に、 [ルーティングの設定](/ja/6.1/topics/db/multi-db/#topics-db-multi-db-routing) によってテスト用でないデータベースに対してクエリが発行される可能性があるためです。 ## `coverage.py` との統合 コードカバレッジは、ソースコードがどれだけテストされたかを表します。コードカバレッジは、コードのどの部分がテストで実施され、 どの部分が実施されていないのかを表します。アプリケーションをテストする上で重要な要素なので、テストのカバレッジをチェックすることを強く推奨します。 Django は Python プログラムのコードカバレッジを測定するツール [coverage.py](https://coverage.readthedocs.io/) と簡単に統合できます。まず、 [coverage](https://pypi.org/project/coverage/) をインストールします。次に、 `manage.py` を含むプロジェクトフォルダから以下を実行してください: ```shell coverage run --source='.' manage.py test myapp ``` これはテストを実行し、プロジェクト内で実行されたファイルのカバレッジデータを収集します。次のコマンドを入力すると、このデータのレポートを見ることができます: ```shell coverage report ``` テストの実行中に、いくつかの Django コードが実行されましたが、前のコマンドに `source` フラグが渡されたため、ここには記載されていないことに注意してください。 テストに失敗した行の詳細を注釈を付けてHTMLに表示するなどのオプションについては、 [coverage.py](https://coverage.readthedocs.io/) のドキュメントを参照してください。