ドキュメントは2つの大きなセクションに分けられます。前半のパートでは、Django でのテストの書き方を説明します。後半では、テストの実行の仕方について説明します。
\nDjango のユニットテストには、Python スタンダードライブラリのモジュール、unittest を使用します。このモジュールは、テストをクラスベースのアプローチで定義します。
次の例では、 unittest.TestCase のサブクラスである django.test.TestCase から、テスト用の新しいサブクラスを作っています。各テストをトランザクションの内側で実行することで、独立性を実現しています。
from django.test import TestCase\nfrom myapp.models import Animal\n\nclass AnimalTestCase(TestCase):\n def setUp(self):\n Animal.objects.create(name="lion", sound="roar")\n Animal.objects.create(name="cat", sound="meow")\n\n def test_animals_can_speak(self):\n """Animals that can speak are correctly identified"""\n lion = Animal.objects.get(name="lion")\n cat = Animal.objects.get(name="cat")\n self.assertEqual(lion.speak(), 'The lion says "roar"')\n self.assertEqual(cat.speak(), 'The cat says "meow"')\n自分で描いたテストを実行する とき、テストユーティリティのデフォルトの動作は次のようなものです。まず、 test で始まる名前を持つファイルからすべてのテストケース (つまり unittest.TestCase のすべてのサブクラス) を見つけ出します。次に、それらテストケースのテストスイートを自動的にビルドします。そして、ビルドしたテストスイートを実行します。
unittest の詳細については、Python のドキュメントを読んでください。
テストが書けたら、プロジェクトの manage.py ユーティリティの test コマンドでテストが実行できます。
$ ./manage.py test\nテストの探索方法は、unittest モジュールの built-in test discovery にもとづきます。デフォルトでは、カレントディレクトリにある "test*.py" という名前の全てのファイルからテストを探し出します。
\n/manage.py test に好きな数の「テストラベル」を与えることで、特定のテストを指定することもできます。各テストラベルには、パッケージ、モジュール、 TestCase サブクラス、テストメソッドへのドット区切りの Python パスを指定します。たとえば:
# Run all the tests in the animals.tests module\n$ ./manage.py test animals.tests\n\n# Run all the tests found within the 'animals' package\n$ ./manage.py test animals\n\n# Run just one test case\n$ ./manage.py test animals.tests.AnimalTestCase\n\n# Run just one test method\n$ ./manage.py test animals.tests.AnimalTestCase.test_animals_can_speak\nディレクトリ下に置かれたテストを探索するために、ディレクトリのパスを指定することもできます。
\n$ ./manage.py test animals/\n-p (または --pattern) オプションを使って、カスタムのファイル名のパターンマッチを指定すれば、テストファイルの名前が test*.py というパターンとは違っていても実行することができます。
$ ./manage.py test --pattern="tests_*.py"\nテストの実行中に Ctrl-C を押すと、テストランナーは現在実行中のテストが完了するのを待って、gracefully にテストを終了します。graceful な終了では、テストランナーは失敗したテストの詳細を出力し、実行したテストの数と、エラーおよび失敗したテストの数をレポートし、通常通りにテストデータベースを破棄します。そのため、 Ctrl-C を押すのは、たとえば、 --failfast オプションを付けるのを忘れて、思わぬテストが失敗したとき、すべてのテストが終わるのを待たずにその失敗の詳細をすぐに知りたいような場合に大変役に立ちます。
現在実行中のテストの終了も待ちたくないときは、もう一度 Ctrl-C を押すことで、テストを graceful ではなく、すぐに強制終了することができます。その場合、強制終了前に実行していたテストの詳細はリポートされず、実行中に作られたテストデータベースも破棄されません。
データベースを必要とするテスト (すなわち、モデルテスト) には、"実際の" (production) 環境のデータベースは使用しません。代わりに、テスト用の空のデータベースを用意します。
\nテストが成功したかどうかにかかわらず、すべてのテストの実行が終わった時点で、テストデータベースは破棄されます。
\ntest --keepdb オプションを指定すれば、テストデータベースの破棄を防ぐことができます。これにより、複数回テストを実行しても、テストデータベースを保存することができます。データベースが存在しないときは、最初に新しく作成され、そしてデータベースが最新の状態になるように、マイグレーションが順番に実行されます。
As described in the previous section, if a test run is forcefully interrupted,\nthe test database may not be destroyed. On the next run, you'll be asked\nwhether you want to reuse or destroy the database. Use the test\n--noinput option to suppress that prompt and automatically destroy the\ndatabase. This can be useful when running tests on a continuous integration\nserver where tests may be interrupted by a timeout, for example.
テストデータベースのデフォルトの名前は、 DATABASES 設定内の各 NAME の値の前に test_ を付けたものになります。SQLite を使っているときは、デフォルトでは、テストにはインメモリのデータベースを使います (つまり、データベースはメモリ内に作成されるため、ファイルシステムへのアクセスを完全になくすことができるのです！)。設定の DATABASES 内の TEST ディクショナリには、テストデータベースに対するいろいろな設定を書くことができます。例えば、別のデータベース名を指定したければ、 TEST ディクショナリの NAME に、 DATABASES の中から好きなデータベースを選んで指定することができます。
PostgreSQL では、 USER が、ビルトインの postgres データベースへの読み取りアクセス権も持っている必要があります。
テストランナーの使うデータベースは、独立したデータベースだけでなく、設定ファイルで指定した通りのデータベースを使用させることもできます: ENGINE, USER, HOST, などです。テストデータベースは、USER で指定されたユーザによって作成されるため、そのユーザアカウントがシステム上で新しくデータベースを作成できる権限を持っている必要があります。
テストデータベースの文字エンコーディングに対するきめ細かい対応をするために、CHARSET TEST オプションを使用してください。MySQL を使用している場合は、COLLATION オプションを使用してテストデータベースが使用する特別な照合をコントロールすることができます。 これらおよびより進歩的な設定の詳細については、設定のドキュメント を参照してください。
If using an SQLite in-memory database with SQLite, shared cache is enabled, so you can write tests\nwith ability to share the database between threads.
\n\n\nすべての TestCase コードがクリーンなデータベースで実行されることを保証するために、Django のテストランナーは次の方法でテストの実行順序を決定します。
すべての TestCase サブクラスが最初に実行されます。
つぎに、すべての Django ベースのテスト (TransactionTestCase を含む SimpleTestCase から作ったテストケース) を、実行順序が保証されず、また強制もされないような適当な順番で実行します。
最後に、その他の unittest.TestCase テスト (doctests を含む) が実行されます。このテストの中には、データベースを変更し、そのまま元の状態に戻さないようなテストがあることもあります。
You may randomize and/or reverse the execution order inside groups using the\ntest --shuffle and --reverse options. This\ncan help with ensuring your tests are independent from each other.
マイグレーションで呼び出されるあらゆる初期データは、TestCase テスト内のみで有効で、 TransactionTestCase 内では無効です。加えて、トランザクションがサポートされるバックエンドのみで有効です (最も重要な例外は MyISAM です)。これは、LiveServerTestCase や StaticLiveServerTestCase といった TransactionTestCase に依存するテストに関しても同様です。
Django can reload that data for you on a per-testcase basis by\nsetting the serialized_rollback option to True in the body of the\nTestCase or TransactionTestCase, but note that this will slow down\nthat test suite by approximately 3x.
Third-party apps or those developing against MyISAM will need to set this;\nin general, however, you should be developing your own projects against a\ntransactional database and be using TestCase for most tests, and thus\nnot need this setting.
The initial serialization is usually very quick, but if you wish to exclude\nsome apps from this process (and speed up test runs slightly), you may add\nthose apps to TEST_NON_SERIALIZED_APPS.
To prevent serialized data from being loaded twice, setting\nserialized_rollback=True disables the\npost_migrate signal when flushing the test\ndatabase.
設定ファイルで指定した DEBUG の値にかかわらず、Django のテストは DEBUG=False を指定したものとして実行されます。これは、表示されるコードの出力が、実際の環境設定で見られるものと同じになるようにするためです。
Caches are not cleared after each test, and running "manage.py test fooapp" can\ninsert data from the tests into the cache of a live system if you run your\ntests in production because, unlike databases, a separate "test cache" is not\nused. This behavior may change in the future.
\nテストを実行すると、テストランナーが用意したたくさんのメッセージが表示されます。表示するメッセージの詳細レベルは、コマンドラインで verbosity オプションを指定することで、自由にコントロールできます。
Creating test database...\nCreating table myapp_animal\nCreating table myapp_mineral\nこのメッセージは、テストランナーが前のセクションで説明したテスト用のデータベースを作成していることを表しています。
\nテスト用データベースが作成されると、Django はテストを実行します。すべてのテストが成功すれば、次のようなメッセージが表示されるはずです。
\n----------------------------------------------------------------------\nRan 22 tests in 0.221s\n\nOK\nしかし、もしテストが失敗した場合には、どのテストが失敗したのかとその詳細が表示されます。
\n======================================================================\nFAIL: test_was_published_recently_with_future_poll (polls.tests.PollMethodTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n File "/dev/mysite/polls/tests.py", line 16, in test_was_published_recently_with_future_poll\n self.assertIs(future_poll.was_published_recently(), False)\nAssertionError: True is not False\n\n----------------------------------------------------------------------\nRan 1 test in 0.003s\n\nFAILED (failures=1)\nこのエラー出力の詳しい説明は、このドキュメントの範囲外ですが、極めて直感的に理解できるものです。詳しく知りたければ、Python の unittest ライブラリのドキュメントを読んでみてください。
失敗したテストやおかしなテストが複数あったとしても、テストランナーのスクリプトから返ってくる終了コードは 1 であることに注意してください。すべてのテストが成功すれば、0 が返ります。この特徴は、別のシェルスクリプトの中でテストランナースクリプトを実行するときに、成功したかどうかの情報が必要な時に役に立ちます。
\n各テストが適切に独立性を保ったものであれば、マルチコアのハードウェア上でテストを並列実行することでスピートアップさせることができます。詳しくは test --parallel を読んでください。
デフォルトのパスワードのハッシュ生成器は、設計上、時間のかかるものになっています。テストの中で多数のユーザーを認証する必要がある場合、カスタムの設定ファイルを用意して、PASSWORD_HASHERS 設定に、より高速なハッシュ生成アルゴリズムを設定すると良いでしょう。
PASSWORD_HASHERS = [\n 'django.contrib.auth.hashers.MD5PasswordHasher',\n]\nPASSWORD_HASHERS には、必要なハッシュアルゴリズムが複数あっても、追加しておくことを忘れないようにしてください。
test --keepdb オプションで、テスト間でテストデータベースを保存することができます。テスト実行の際、データベース作成および破棄にかかる時間を大幅に短縮できます。