ドキュメントは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自分で描いたテストを実行する <running-tests>`とき、テストユーティリティのデフォルトの動作は次のようなものです。まず、``test` で始まる名前を持つファイルからすべてのテストケース (つまり unittest.TestCase のすべてのサブクラス) を見つけ出します。次に、それらテストケースのテストスイートを自動的にビルドします。そして、ビルドしたテストスイートを実行します。
unittest の詳細については、Python のドキュメントを読んでください。
テストが書けたら、プロジェクトの manage.py ユーティリティの test コマンドでテストが実行できます。
$ ./manage.py test\nテストの探索方法は、unittest モジュールの built-in test discovery にもとづきます。デフォルトでは、カレントディレクトリにある "test*.py" という名前の全てのファイルからテストを探し出します。
\nYou can specify particular tests to run by supplying any number of "test labels" to ./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 オプションを指定すれば、テストデータベースの破棄を防ぐことができます。これにより、複数回テストを実行しても、テストデータベースを保存することができます。データベースが存在しないときは、最初に新しく作成され、そしてデータベースが最新の状態になるように、マイグレーションが順番に実行されます。
テストデータベースのデフォルトの名前は、 DATABASES 設定内の各 NAME の値の前に test_ を付けたものになります。SQLite を使っているときは、デフォルトでは、テストにはインメモリのデータベースを使います (つまり、データベースはメモリ内に作成されるため、ファイルシステムへのアクセスを完全になくすことができるのです！)。設定の DATABASES 内の TEST ディクショナリには、テストデータベースに対するいろいろな設定を書くことができます。例えば、別のデータベース名を指定したければ、 TEST ディクショナリの NAME に、 DATABASES の中から好きなデータベースを選んで指定することができます。
PostgreSQL では、 USER が、ビルトインの postgres データベースへの読み取りアクセス権も持っている必要があります。
Aside from using a separate database, the test runner will otherwise\nuse all of the same database settings you have in your settings file:\nENGINE, USER, HOST, etc. The\ntest database is created by the user specified by USER, so you'll\nneed to make sure that the given user account has sufficient privileges to\ncreate a new database on the system.
For fine-grained control over the character encoding of your test\ndatabase, use the CHARSET TEST option. If you're using\nMySQL, you can also use the COLLATION option to\ncontrol the particular collation used by the test database. See the\nsettings documentation for details of these\nand other advanced settings.
If using an SQLite in-memory database with Python 3.4+ and SQLite 3.7.13+,\nshared cache will be enabled, so\nyou can write tests with ability to share the database between threads.
\n\n\nすべての TestCase コードがクリーンなデータベースで実行されることを保証するために、Django のテストランナーは次の方法でテストの実行順序を決定します。
すべての TestCase サブクラスが最初に実行されます。
つぎに、すべての Django ベースのテスト (TransactionTestCase を含む SimpleTestCase から作ったテストケース) を、実行順序が保証されず、また強制もされないような適当な順番で実行します。
最後に、その他の unittest.TestCase テスト (doctests を含む) が実行されます。このテストの中には、データベースを変更し、そのまま元の状態に戻さないようなテストがあることもあります。
You may reverse the execution order inside groups using the test\n--reverse option. This can help with ensuring your tests are independent from\neach other.
Any initial data loaded in migrations will only be available in TestCase\ntests and not in TransactionTestCase tests, and additionally only on\nbackends where transactions are supported (the most important exception being\nMyISAM). This is also true for tests which rely on TransactionTestCase\nsuch as LiveServerTestCase and\nStaticLiveServerTestCase.
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 を指定したものとして実行されます。これは、表示されるコードの出力が、実際の環境設定で見られるものと同じになるようにするためです。
各テスト後にキャッシュはクリアされません。そのため、"manage.py test fooapp" を実行すると、テストで挿入されたデータが実働環境のシステムのキャッシュに残り続ける可能性があります。データベースの場合と違い、別の「テスト用のキャッシュ」が使われないためです。ただし、将来、この動作は 変更される可能性があります 。
\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 には、必要なハッシュアルゴリズムが複数あっても、追加しておくことを忘れないようにしてください。
The test --keepdb option preserves the test database between test\nruns. It skips the create and destroy actions which can greatly decrease the\ntime to run tests.