提供されるテストケースのクラスLink to this heading#
\n標準の Python ユニットテストのクラスは、unittest.TestCase のベースクラスを拡張しています。Django は、このベースクラスのいくつかの拡張を提供します:
![\"Hierarchy](\"../../../../../../_images/django_unittest_classes_hierarchy.svg\")
\n\nHierarchy of Django unit testing classesLink to this image#
\nConverting a normal unittest.TestCase to any of the subclasses is\neasy: change the base class of your test from unittest.TestCase to the\nsubclass. All of the standard Python unit test functionality will be available,\nand it will be augmented with some useful additions as described in each\nsection below.
SimpleTestCaseLink to this heading#
\n- \n
- \nclass SimpleTestCaseLink to this definition# \n
以下の機能を追加する、unittest.TestCase のサブクラスです:
- \n
以下のような便利なアサーション:
\n- \n
Checking that a callable
raises a certain exception. \nTesting form field
rendering and error treatment. \nTesting
HTML responses for the presence/lack of a given fragment. \nVerifying that a template
has/hasn't been used to generate a given\nresponse content. \nVerifying a HTTP
redirectis\nperformed by the app. \nRobustly testing two
HTML fragments\nfor equality/inequality orcontainment. \nRobustly testing two
XML fragments\nfor equality/inequality. \nRobustly testing two
JSON fragments\nfor equality. \n
\n編集した設定 でテストを実行する機能。
\n- \n
データベースクエリを作る手薄との場合、サブクラス TransactionTestCase や TestCase を使用してください。
- \n
- \nSimpleTestCase.allow_database_queriesLink to this definition# \n
\nSimpleTestCasedisallows database queries by default. This\nhelps to avoid executing write queries which will affect other tests\nsince eachSimpleTestCasetest isn't run in a transaction. If you\naren't concerned about this problem, you can disable this behavior by\nsetting theallow_database_queriesclass attribute toTrueon\nyour test class.
TransactionTestCaseLink to this heading#
\n- \n
- \nclass TransactionTestCaseLink to this definition# \n
TransactionTestCase は SimpleTestCase を継承し、データベースに特有の機能を追加しています:
- \n
Resetting the database to a known state at the beginning of each test to\nease testing and using the ORM.
\nDatabase
fixtures. \n- \n
The remaining specialized
assert*methods. \n
Django's TestCase class is a more commonly used subclass of\nTransactionTestCase that makes use of database transaction facilities\nto speed up the process of resetting the database to a known state at the\nbeginning of each test. A consequence of this, however, is that some database\nbehaviors cannot be tested within a Django TestCase class. For instance,\nyou cannot test that a block of code is executing within a transaction, as is\nrequired when using\nselect_for_update(). In those cases,\nyou should use TransactionTestCase.
TransactionTestCase and TestCase are identical except for the manner\nin which the database is reset to a known state and the ability for test code\nto test the effects of commit and rollback:
- \n
A
TransactionTestCaseresets the database after the test runs by\ntruncating all tables. ATransactionTestCasemay call commit and rollback\nand observe the effects of these calls on the database. \nA
TestCase, on the other hand, does not truncate tables after a test.\nInstead, it encloses the test code in a database transaction that is rolled\nback at the end of the test. This guarantees that the rollback at the end of\nthe test restores the database to its initial state. \n
TestCaseLink to this heading#
\n- \n
- \nclass TestCaseLink to this definition# \n
これは、Django でテストを書く際に使われる、最も一般的なクラスです。TransactionTestCase (と拡張による SimpleTestCase) を継承します。あなたの Django アプリケーションがデータベースを使用しない場合は、SimpleTestCase を使ってください。
クラス:
\n- \n
2 つのネストされた
atomic()ブロックでテストをラップします: 1 つはテスト全体、もう 1 つは各テストのためです。したがって、特定のデータベーストランザクションの振る舞いをテストしたい場合は、TransactionTestCaseを使ってください。 \n各テストの最後に、deferrable なデータベース制約をチェックします。
\n
さらに追加メソッドを提供します:
\n- \n
- \nclassmethod TestCase.setUpTestData()Link to this definition# \n
上述のクラスレベルの
\natomicブロックは、全体のTestCaseに対して一度、クラスレベルでの初期データの作成を可能にします。 この技法により、setUp()を使うのに比べて高速なテストとなります。For example:
\n\nfrom django.test import TestCase\n\nclass MyTests(TestCase):\n @classmethod\n def setUpTestData(cls):\n # Set up data for the whole TestCase\n cls.foo = Foo.objects.create(bar="Test")\n ...\n\n def test1(self):\n # Some test using self.foo\n ...\n\n def test2(self):\n # Some other test using self.foo\n ...\nテストがトランザクションサポートのないデータベース (たとえば MyISAM エンジンの MySQL) で実行される場合、各テストの前に
\nsetUpTestData()が呼ばれ、高速化のメリットはなくなります。テストメソッドを書く中で、
\nsetUpTestData()内で生成されたオブジェクトを変更してしまわないように気をつけてください。クラスレベルで行われたセットアップ動作からのインメモリーオブジェクトを修正することは、テストメソッド間で持続します。オブジェクトを編集する必要のあるときは、たとえばsetUp()メソッド内でrefresh_from_db()とともにリロードしてください。
LiveServerTestCaseLink to this heading#
\n- \n
- \nclass LiveServerTestCaseLink to this definition# \n
LiveServerTestCase は TransactionTestCase とほぼ同じですが、追加機能を 1 つ持ちます: セットアップ時に実際の Django サーバーをバックグラウンドでローンチし、 終了時に破棄します。これにより、たとえば Selenium client のような Django ダミークライアント 以外の自動化されたテストクライアントを使えるようになり、ブラウザ内での一連の機能テストを実施して実際のユーザーの行動をシミュレートできます。
The live server listens on localhost and binds to port 0 which uses a free\nport assigned by the operating system. The server's URL can be accessed with\nself.live_server_url during the tests.
To demonstrate how to use LiveServerTestCase, let's write a simple Selenium\ntest. First of all, you need to install the selenium package into your\nPython path:
$ pip install selenium\nThen, add a LiveServerTestCase-based test to your app's tests module\n(for example: myapp/tests.py). For this example, we'll assume you're using\nthe staticfiles app and want to have static files served\nduring the execution of your tests similar to what we get at development time\nwith DEBUG=True, i.e. without having to collect them using\ncollectstatic. We'll use\nthe StaticLiveServerTestCase\nsubclass which provides that functionality. Replace it with\ndjango.test.LiveServerTestCase if you don't need that.
The code for this test may look as follows:
\nfrom django.contrib.staticfiles.testing import StaticLiveServerTestCase\nfrom selenium.webdriver.firefox.webdriver import WebDriver\n\nclass MySeleniumTests(StaticLiveServerTestCase):\n fixtures = ['user-data.json']\n\n @classmethod\n def setUpClass(cls):\n super().setUpClass()\n cls.selenium = WebDriver()\n cls.selenium.implicitly_wait(10)\n\n @classmethod\n def tearDownClass(cls):\n cls.selenium.quit()\n super().tearDownClass()\n\n def test_login(self):\n self.selenium.get('%s%s' % (self.live_server_url, '/login/'))\n username_input = self.selenium.find_element_by_name("username")\n username_input.send_keys('myuser')\n password_input = self.selenium.find_element_by_name("password")\n password_input.send_keys('secret')\n self.selenium.find_element_by_xpath('//input[@value="Log in"]').click()\nFinally, you may run the test as follows:
\n$ ./manage.py test myapp.tests.MySeleniumTests.test_login\nThis example will automatically open Firefox then go to the login page, enter\nthe credentials and press the "Log in" button. Selenium offers other drivers in\ncase you do not have Firefox installed or wish to use another browser. The\nexample above is just a tiny fraction of what the Selenium client can do; check\nout the full reference for more details.
\n\n