テストに関する高度なトピック¶
RequestFactory(リクエスト ファクトリ)¶
RequestFactory
はテストクライアントと同じ API を共有しています。しかし、ブラウザのように動作するのではなく、 RequestFactory は任意のビューの最初の引数として使用できるリクエストインスタンスを生成する方法を提供します。つまり、ビュー関数を他の関数をテストするのと同じ方法で テストできます。入力が完全にわかっているブラックボックスとして、特定の出力をテストできます。
RequestFactory
の API は、テストクライアント API の少し制限されたサブセットです:
- RequestFactoryは、HTTPメソッドの
get()
,post()
,put()
,delete()
,head()
,options()
,trace()
にだけアクセスできます。 - これらのメソッドは
follow
以外 はすべて同じ引数を受け取ります。これはリクエストを生成するための単なるファクトリ(工場)なので、 レスポンスの処理はあなた次第です。 - ミドルウェアはサポートしていません。セッション属性と認証属性は、ビューが正しく機能するために必要であれば、テスト自身が持たなければなりません。
The query_params
parameter was added.
カスタマイズ例¶
以下はリクエスト・ファクトリを使ったユニットテストです:
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
インスタンスを返すことです。そのメソッドはすべて同期呼び出し可能オブジェクトのままです。
defaults
内の任意のキーワード引数は直接ASGIスコープに追加されます。
The query_params
parameter was added.
クラスベースのビューをテストする¶
リクエスト/レスポンスサイクルの外でクラスベースのビューをテストするには、インスタンス化後に 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()
メソッドを直接テストするには、まずビューをインスタンス化して setup()
に request
を渡します:
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 と外部 URL を区別できるようになります。
マルチテナントをサポートするプロジェクトや、リクエストのホストに基づいてビジネスロジックを変更するプロジェクトで、カスタムホスト名をテストで使用する場合は、それらのホストを 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", ...]
2つめの選択肢は、 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 へのリダイレクトを辿ったときにテストクライアントが役立つエラーメッセージを表示しないようになります。
テストと複数データベース¶
プライマリ/レプリカ構成のテスト¶
プライマリ/レプリカ(データベースによってはマスタ/スレーブとも呼ばれる)レプリケーションを使用した複数データベース構成をテストする場合、テスト用データベースを作成するこの方法には問題があります。テスト用データベースを作成すると、レプリケーションが行われなくなり、その結果、プライマリで作成されたデータがレプリカで見られなくなります。
これを補うために、 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
を使っています)、テストでは replica
は default
のミラーとして扱われるはずです。
テスト環境が設定されると、テストバージョンの replica
は作成されません。代わりに replica
への接続は default
を指すようにリダイレクトされます。その結果、default
への書き込みは replica
に表示されますが、これは実際には同じデータベースであることが原因であり、2つのデータベース間でデータの複製が行われていることが原因ではありません。これはトランザクションに依存しているので、テストでは TestCase
ではなく TransactionTestCase
を使う必要があります。
テストデータベースの作成順をコントロールする¶
デフォルトでは、 Django は全てのデータベースが default
データベースに依存しているとみなすので、常に default
データベースを最初に作成します。しかし、テストセットアップの他のデータベースの作成順は保証されません。
データベース構成が特定の作成順序を必要とする場合、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
の定義に循環依存がある場合、 ImproperlyConfigured
例外が発生します。
TransactionTestCase
の高度な機能¶
-
TransactionTestCase.
available_apps
¶ 警告
この属性はプライベートAPIです。例えば、アプリケーションの読み込みの変更に対応するために、将来、非推奨期間なしに変更または削除される可能性があります。
これは Django 自身のテストスイートを最適化するために使われます。このテストスイート には何百ものモデルが含まれますが、異なるアプリケーションのモデル間のリレーションはありません。
デフォルトでは、
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
¶ 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 のデフォルトのテスト動作を定義します。この動作には下記が含まれます:
- テスト前のグローバルなセットアップの実行。
- 現在のディレクトリ以下のファイルの中から、名前が
test*.py
と一致するテストを探す。 - テストデータベースの作成。
- テストデータベースにモデルと初期データをインストールするために
migrate
を実行する。 - システムチェック の実行。
- 見つかったテストを実行する。
- テストデータベースの破棄。
- テスト後のグローバルな後処理の実行。
独自のテストランナークラスを定義し、 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
の場合、テストケースは逆の順番で実行されます。これは適切に分離されておらず、副作用があるテストをデバッグするのに便利です。 テストクラス によるグループ化は、このオプションを使用しても保持されます。このオプションは--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
コマンドがそれらの引数を使用できるようになります。New in Django 5.0:durations
引数が追加されました。
属性¶
-
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()
を参照してください)。このメソッドは、失敗したテストの数を返す必要があります。
-
classmethod
DiscoverRunner.
add_arguments
(parser)[ソース]¶ このクラスメソッドをオーバーライドして
test
管理コマンドが受け付けるカスタム引数を追加できます。パーサへの引数の追加についての詳細はargparse.ArgumentParser.add_argument()
を参照してください。
-
DiscoverRunner.
setup_test_environment
(**kwargs)[ソース]¶ setup_test_environment()
を呼び出して、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()
を呼び出して、テスト用データベースを作成します。
-
DiscoverRunner.
teardown_databases
(old_config, **kwargs)[ソース]¶ teardown_databases()
を呼び出すことで、テストデータベースを破棄し、テスト前の状態に戻します。
-
DiscoverRunner.
log
(msg, level=None)[ソース]¶ もし
logger
が設定されている場合、与えられた整数の logging level (例えば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
設定はその値に更新されます。
-
teardown_test_environment
()[ソース]¶ グローバルな後処理テストのテアダウン(解体)を実行します。これには、テンプレートシステムから計測ツールを削除し、通常のメールサービスを復元することが含まれます。
-
setup_databases
(verbosity, interactive, *, time_keeper=None, keepdb=False, debug_sql=False, parallel=0, aliases=None, serialized_aliases=None, **kwargs)[ソース]¶ テスト用データベースを作成します。
行われた変更を元に戻すのに十分な詳細情報を提供するデータ構造を返します。このデータはテスト終了時に
teardown_databases()
関数に渡されます。引数
aliases
はどのDATABASES
エイリアスにテスト用データベースを設定するかを決定します。省略された場合、デフォルトはDATABASES
の全てのエイリアスです。serialized_aliases
引数は、aliases
テストデータベースのどのサブセットがその状態をシリアライズすべきかを特定し、 serialized_rollback 機能が利用できるようにします。指定しなかった場合、デフォルトはaliases
になります。
-
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 文字列にシリアライズするかどうかを決定します (トランザクションがない場合、テスト間でデータベースの状態を復元するために使います)。これをFalse
に設定すると、 serialized_rollback=True を持つテストクラスがない場合に、作成時間を短縮できます。keepdb
はテスト実行時に既存のデータベースを使用するか、新しいデータベースを作成するかを決定します。もしTrue
なら、既存のデータベースが使用され、存在しない場合は作成されます。もしFalse
ならば、新しいデータベースが作成され、既存のデータベースを削除するようにユーザに促します。作成したテスト用データベースの名前を返します。
create_test_db()
はDATABASES
のNAME
の値をテストデータベースの名前と一致するように変更するという副作用があります。
-
destroy_test_db
(old_database_name, verbosity=1, keepdb=False)¶ DATABASES
のNAME
の値を名前とするデータベースを破棄し、NAME
にold_database_name
の値をセットします。verbosity
引数はDiscoverRunner
と同じ動作です。keepdb
引数がTrue
の場合、データベースへの接続は閉じられますが、データベースは破棄されません。
coverage.py
との統合¶
コードカバレッジは、ソースコードがどれだけテストされたかを表します。コードカバレッジは、コードのどの部分がテストで実施され、 どの部分が実施されていないのかを表します。アプリケーションをテストする上で重要な要素なので、テストのカバレッジをチェックすることを強く推奨します。
Django は Python プログラムのコードカバレッジを測定するツール coverage.py と簡単に統合できます。まず、 coverage をインストールします。次に、 manage.py
を含むプロジェクトフォルダから以下を実行してください:
coverage run --source='.' manage.py test myapp
これはテストを実行し、プロジェクト内で実行されたファイルのカバレッジデータを収集します。次のコマンドを入力すると、このデータのレポートを見ることができます:
coverage report
テストの実行中に、いくつかの Django コードが実行されましたが、前のコマンドに source
フラグが渡されたため、ここには記載されていないことに注意してください。
テストに失敗した行の詳細を注釈を付けてHTMLに表示するなどのオプションについては、 coverage.py のドキュメントを参照してください。