--- title: "テストツール" version: 5.2 locale: ja source: https://docs.djangoproject.com/ja/5.2/topics/testing/tools/ canonical: https://djangodocs.dev/ja/5.2/topics/testing/tools/ --- # テストツール Django は、テストを書くのに便利なツールをいくつか提供しています。 ## テストクライアントテストクライアントは、ダミーのウェブブラウザとして振る舞う Python のクラスです。これを使えば、ビューと Django で作ったアプリケーションとの関係をプログラムから自動でテストできるようになります。テストクライアントでは、次のようなことができます。 - ある URL に対する GET および POST リクエストのシミュレートと、その結果の観察。低レベルの HTTP (レスポンスのヘッダーやステータスコードなど) から、ページのコンテンツまで、あらゆるレスポンスの内容を調査できます。 - 一連の (好きな数の) リダイレクトを見て、その各ステップごとに URL とステータスコードをチェックする。 - 指定したリクエストが特定の Django テンプレートによってレンダリングされたとき、テンプレートのコンテキストが正しく特定の値を含んでいるかどうかをテストする。テストクライアントは [Selenium](https://www.selenium.dev/) や他の "ブラウザ内 (in-browser)" フレームワークの代替を目指すものではないことに注意してください。Django のテストクライアントの目的は別の点にあります。つまり、 - Django のテストクライアントは、正しいテンプレートがレンダリングされ、そのテンプレートが正しいコンテキストデータをちゃんと渡しているのかをチェックするために使います。 - ビューの機能を直接テストするには、[`RequestFactory`](/ja/5.2/topics/testing/advanced/#django.test.RequestFactory) を使用して、ルーティングとミドルウェアのレイヤーをバイパスしてください。 - [Selenium](https://www.selenium.dev/) などのブラウザー内フレームワークは、HTML の *レンダリング* や、ウェブページの *振る舞い* 、つまり JavaScript の機能性をテストするために使います。また、Django はこれらのフレームワーク向けの特別なサポートも提供しています。詳細については、[`LiveServerTestCase`](#django.test.LiveServerTestCase) のセクションを読んでください。包括的なテストスイートを実現するには、これらすべてのタイプのテストを組み合わせて行うべきです。 ### 概要と簡単な例テストクライアントを使うには、`django.test.Client` からインスタンスを作り、次のようにウェブページを取得します。 ```pycon >>> from django.test import Client >>> c = Client() >>> response = c.post("/login/", {"username": "john", "password": "smith"}) >>> response.status_code 200 >>> response = c.get("/customer/details/") >>> response.content b'>> c.get("/login/") ``` しかし、これは間違いです。 ```pycon >>> c.get("https://www.example.com/login/") ``` テストクライアントには、自分の Django プロジェクト以外のウェブページを取得する機能はありません。他のウェブページが必要な場合には、 [`urllib`](https://docs.python.org/3/library/urllib.html#module-urllib) などの Python のスタンダードライブラリモジュールを利用してください。 - URL を解決するとき、テストクライアントは [`ROOT_URLCONF`](/ja/5.2/ref/settings/#std-setting-ROOT_URLCONF) 設定で指定されたすべての URLconf を使用します。 - 上の例では Python のインタラクティブなインタプリタ上でも動作するはずですが、テストクライアントの一部の機能、特にテンプレート関係の機能は、 *テストの実行中* にしか使えないことがあります。というのも、Django のテストランナーは、与えられたビューによって読み込まれるテンプレートを決定する時に、ちょっとした黒魔術を使っています。この黒魔術 (具体的には Django のテンプレートシステムに対してメモリ上でパッチを当てています) は、テストの実行中にだけ使われるのです。 - デフォルトでは、テストクライアントはサイト上でのすべての CSRF チェックを無効にしています。何らかの理由でテストクライアントに CSRF チェックを実行して *ほしい* ときには、CSRF チェックの実行を強制するテストクライアントのインスタンスを作ることができます。これには、クライアントを作る時に次のように `enforce_csrf_checks` 引数を渡します。 ```pycon >>> from django.test import Client >>> csrf_client = Client(enforce_csrf_checks=True) ``` ### リクエストの作成リクエストの作成には、`django.test.Client` クラスを使います。 #### `class Client(enforce_csrf_checks=False, raise_request_exception=True, json_encoder=DjangoJSONEncoder, * (Keyword-only parameters separator (PEP 3102)), headers=None, query_params=None, **defaults)` テスト用の HTTP クライアントです。いくつかの引数で動作をカスタマイズできます。 `headers` にはリクエストごとに送信されるデフォルトのヘッダを指定できます。例えば、 `User-Agent` ヘッダの場合: ``` client = Client(headers={"user-agent": "curl/7.79.1"}) ``` `query_params` を使用すると、すべてのリクエストに設定されるデフォルトのクエリ文字列を指定できます。 `Defaults` 内の任意のキーワード引数には WSGI [**環境変数**](https://peps.python.org/pep-3333/#environ-variables) を指定します。例えば、スクリプト名の場合: ``` client = Client(SCRIPT_NAME="/app/") ``` > **Note** > > `HTTP_` プレフィックスで始まるキーワード引数がヘッダーとして設定されますが、可読性のために `headers` パラメーターの使用を推奨します。 [`get()`](#django.test.Client.get) や [`post()`](#django.test.Client.post) などに渡される `headers`、`query_params`、および `extra` キーワード引数の値は、クラスコンストラクタに渡されたデフォルト値よりも優先されます。 `enforce_csrf_checks` 引数を使うと、CSRF プロテクションのテストが実行できます (上の説明を参照)。 `raise_request_exception` 引数を指定することで、リクエスト中に発生した例外をテストでも発生させるかどうかを制御できます。デフォルトは `True` です。 `json_encoder` 引数を指定すると、 [`post()`](#django.test.Client.post) に記述されているJSONシリアライズ用のカスタムJSONエンコーダを指定できます。 > **Changed in Django 5.1** > > `query_params` 引数が追加されました。 `Client` インスタンスを一度作れば、以下のメソッドを自由に使うことができます。 #### `get(path, data=None, follow=False, secure=False, * (Keyword-only parameters separator (PEP 3102)), headers=None, query_params=None, **extra)` 与えられた `path` に対して GET リクエストを作り、`Response` オブジェクトを返します。`Response` オブジェクトについては、下のセクションにドキュメントされています。 `query_params` に渡された辞書のキーと値のペアは、クエリ文字列の設定に使用されます。例えば、次のように使います。 ```pycon >>> c = Client() >>> c.get("/customers/details/", query_params={"name": "fred", "age": 7}) ``` 引数の評価の結果、次の GET リクエストの実行と等価になります。 ```text /customers/details/?name=fred&age=7 ``` これらのパラメータを `data` パラメータに渡すことも可能です。しかし、`query_params` を使用する方が推奨されます。なぜなら、`query_params` はすべてのHTTPメソッドで動作するからです。 `headers` 引数は、リクエスト時に送信されるヘッダーの指定に使われます。たとえば、次のコード ```pycon >>> c = Client() >>> c.get( ... "/customers/details/", ... query_params={"name": "fred", "age": 7}, ... headers={"accept": "application/json"}, ... ) ``` は、HTTP ヘッダー `HTTP_ACCEPT` を details ビューに送信します。これは、 [`django.http.HttpRequest.accepts()`](/ja/5.2/ref/request-response/#django.http.HttpRequest.accepts) メソッドを使ったコードパースのテストのための良い方法です。任意のキーワード引数には、WSGI [**環境変数**](https://peps.python.org/pep-3333/#environ-variables) を指定します。たとえば、スクリプト名を設定するヘッダの場合: ```pycon >>> c = Client() >>> c.get("/", SCRIPT_NAME="/app/") ``` GET の引数がすでに URL エンコードされた形式である場合は、data 引数の代わりにエンコード済みの文字列を使うことができます。たとえば、先ほどの GET リクエストは次のようにも書けます。 ```pycon >>> c = Client() >>> c.get("/customers/details/?name=fred&age=7") ``` エンコード済みのGETデータを含むURLと `query_params` または `data` 引数の両方を指定した場合、これらの引数が優先されます。 `follow` を `True` を与えると、クライアントはすべてのリダイレクトを辿り、途中の URL とステータスコードのタプルが、レスポンスオブジェクトの `redirect_chain` 属性に追加されてゆきます。たとえば、URL `/redirect_me/` が `/next/` にリダイレクトし、それがさらに `/final/` にリダイレクトするような場合には、`redirect_chain` は次のような値になります。 ```pycon >>> response = c.get("/redirect_me/", follow=True) >>> response.redirect_chain [('http://testserver/next/', 302), ('http://testserver/final/', 302)] ``` `secure` を `True` に設定すると、クライアントは HTTPS リクエストをエミュレートします。 > **Changed in Django 5.1** > > `query_params` 引数が追加されました。 #### `post(path, data=None, content_type=MULTIPART_CONTENT, follow=False, secure=False, * (Keyword-only parameters separator (PEP 3102)), headers=None, query_params=None, **extra)` 与えられた `path` に対して POST リクエストを作り、`Response` オブジェクトを返します。`Response` オブジェクトについては、下のセクションにドキュメントされています。 `data` ディクショナリ内の key-value ペアは、POST データを送信するのに使われます。例えば、次の例では、 ```pycon >>> c = Client() >>> c.post("/login/", {"name": "fred", "passwd": "secret"}) ``` 引数の評価の結果、次の URL へ POST リクエストが行われます。 ```text /login/ ``` リクエストで送られる POST データは次のものになります。 ```text name=fred&passwd=secret ``` `content_type` に `application/json` を指定すると、 `data` が dict、リスト、タプルの場合、 [`json.dumps()`](https://docs.python.org/3/library/json.html#json.dumps) を使ってシリアライズされます。デフォルトでは [`DjangoJSONEncoder`](/ja/5.2/topics/serialization/#django.core.serializers.json.DjangoJSONEncoder) でシリアライズを行いますが、 [`Client`](#django.test.Client) に `json_encoder` 引数を指定することでオーバーライドできます。このシリアライズは [`put()`](#django.test.Client.put), [`patch()`](#django.test.Client.patch), [`delete()`](#django.test.Client.delete) リクエストでも行われます。もし他の `content_type` (たとえば、XML データの場合は `text/xml`) を与えると、`data` のコンテンツは、HTTP の `Content-Type` ヘッダーの中で `content_type` を使ったものとして、POST リクエストで送られます。 `content_type` に値を渡さなかったときは、`data` 内の値を `multipart/form-data` のコンテンツタイプとして送信します。この場合は、 `data` 内のkey-value ペアが multipart メッセージにえんこーどされ、POST データを生成するのに使われます。たとえば `', '', ) ``` `html1` と `html2` はHTMLを含んでいなければなりません。どちらかが解析できない場合は `AssertionError` が発生します。エラー時の出力は `msg` 引数でカスタマイズできます。 #### `SimpleTestCase.assertHTMLNotEqual(html1, html2, msg=None)` 文字列 `html1` と `html2` が等しく *ない* ことをアサートします。比較はHTMLのセマンティクスに基づいて行われます。詳細は [`assertHTMLEqual()`](#django.test.SimpleTestCase.assertHTMLEqual) を参照してください。 `html1` と `html2` はHTMLを含んでいなければなりません。どちらかが解析できない場合は `AssertionError` が発生します。エラー時の出力は `msg` 引数でカスタマイズできます。 #### `SimpleTestCase.assertXMLEqual(xml1, xml2, msg=None)` 文字列 `xml1` と `xml2` が等しいことをアサートします。比較はXMLセマンティクスに基づいて行われます。[`assertHTMLEqual()`](#django.test.SimpleTestCase.assertHTMLEqual) と同様に、比較は構文解析された内容に基づいて行われるため、構文の違いは考慮されず、意味の違いだけが考慮されます。無効なXMLがパラメータに渡された場合、両方の文字列が同じであっても、常に `AssertionError` が発生します。 XML宣言、ドキュメントタイプ、処理命令、コメントは無視されます。比較されるのはルート要素とその子要素だけです。エラー時の出力は `msg` 引数でカスタマイズできます。 #### `SimpleTestCase.assertXMLNotEqual(xml1, xml2, msg=None)` 文字列 `xml1` と `xml2` が等しく *ない* ことをアサートします。比較はXMLセマンティクスに基づいて行われます。詳細は [`assertXMLEqual()`](#django.test.SimpleTestCase.assertXMLEqual) を参照してください。エラー時の出力は `msg` 引数でカスタマイズできます。 #### `SimpleTestCase.assertInHTML(needle, haystack, count=None, msg_prefix='')` HTML フラグメント `needle` が `haystack` に含まれていることをアサートします。もし `count` という整数の引数が指定された場合、さらに `needle` の出現数が厳密に検証されます。ほとんどの場合、空白は無視され、属性の順序は重要ではありません。詳細は [`assertHTMLEqual()`](#django.test.SimpleTestCase.assertHTMLEqual) を参照してください。 > **Changed in Django 5.1** > > 以前のバージョンでは、エラーメッセージに `haystack` が含まれていませんでした。 #### `SimpleTestCase.assertNotInHTML(needle, haystack, msg_prefix='')` > **New in Django 5.1** HTMLフラグメント `needle` が `haystack` に含まれて *いない* ことをアサートします。ほとんどの場合、空白は無視され、属性の順序は重要ではありません。詳細は [`assertHTMLEqual()`](#django.test.SimpleTestCase.assertHTMLEqual) を参照してください。 #### `SimpleTestCase.assertJSONEqual(raw, expected_data, msg=None)` JSON フラグメント `raw` と `expected_data` が等しいことをアサートします。重要な部分は [`json`](https://docs.python.org/3/library/json.html#module-json) ライブラリに委譲されているため、通常の JSON の重要でない空白のルールが適用されます。エラー時の出力は `msg` 引数でカスタマイズできます。 #### `SimpleTestCase.assertJSONNotEqual(raw, expected_data, msg=None)` JSON フラグメント `raw` と `expected_data` が等しく *ない* ことをアサートします。詳細は [`assertJSONEqual()`](#django.test.SimpleTestCase.assertJSONEqual) を参照してください。エラー時の出力は `msg` 引数でカスタマイズできます。 #### `TransactionTestCase.assertQuerySetEqual(qs, values, transform=None, ordered=True, msg=None)` クエリセット `qs` が特定の値のイテラブル `values` にマッチすることをアサートします。 `transform` が指定された場合、 `values` は `qs` の各メンバに `transform` を適用したリストと比較されます。デフォルトでは、比較は順序に依存します。もし `qs` が暗黙の順序を提供しない場合、 `ordered` パラメータを `False` に設定することで、比較を `collections.Counter` 比較に変更できます。順序が未定義の場合 (指定された `qs` が順序付けされておらず、複数の順序付けられた値との比較の場合)、`ValueError` が発生します。エラー時の出力は `msg` 引数でカスタマイズできます。 #### `TransactionTestCase.assertNumQueries(num, func, *args, **kwargs)` `func` が `*args` と `**kwargs` で呼び出されると、 `num` 個のデータベースクエリが実行されることをアサートします。もし `kwargs` に `"using"` キーがあれば、それをクエリの数をチェックするためのデータベースのエイリアスとして使用します。 ``` self.assertNumQueries(7, my_function, using="non_default_db") ``` もし `using` パラメータを持つ関数を呼び出したい場合は、呼び出しを `lambda` でラップして追加のパラメータを指定できます。 ``` self.assertNumQueries(7, lambda: my_function(using=7)) ``` コンテキストマネージャとしても使えます。 ``` with self.assertNumQueries(2): Person.objects.create(name="Aaron") Person.objects.create(name="Daniel") ``` ### テストにタグをつけるテストにタグをつけることで、特定のサブセットを簡単に実行できるようになります。たとえば、速いテストや遅いテストにラベルをつけることができます。 ``` from django.test import tag class SampleTestCase(TestCase): @tag("fast") def test_fast(self): ... @tag("slow") def test_slow(self): ... @tag("slow", "core") def test_slow_but_core(self): ... ``` テストケースクラスにタグを付けることもできます。 ``` @tag("slow", "core") class SampleTestCase(TestCase): ... ``` サブクラスは基底クラスからタグを継承し、メソッドはそのクラスからタグを継承します。以下の例を考えてみましょう。 ``` @tag("foo") class SampleTestCaseChild(SampleTestCase): @tag("bar") def test(self): ... ``` `SampleTestCaseChild.test` は `'slow'`, `'core'`, `'bar'`, そして `'foo'` というラベルが付けられます。その後、どのテストを実行するか選択できます。例えば、速いテストのみを実行するには、次にようにします。 ```console $ ./manage.py test --tag=fast ``` *Windows* ```doscon ...\> manage.py test --tag=fast ``` または、速いテストとコアなテスト (それが遅いとしても) を実行することもできます。 ```console $ ./manage.py test --tag=fast --tag=core ``` *Windows* ```doscon ...\> manage.py test --tag=fast --tag=core ``` タグによってテストを除外することもできます。遅くない場合にコアテストを実行するには、次にようにします。 ```console $ ./manage.py test --tag=core --exclude-tag=slow ``` *Windows* ```doscon ...\> manage.py test --tag=core --exclude-tag=slow ``` [`test --exclude-tag`](/ja/5.2/ref/django-admin/#cmdoption-test-exclude-tag) は [`test --tag`](/ja/5.2/ref/django-admin/#cmdoption-test-tag) よりも優先されるので、テストに2つのタグがあり、片方を選択してもう片方を除外すると、テストは実行されません。 ## 非同期コードをテストする単に非同期ビューの出力をテストしたいだけであれば、標準のテストクライアントが非同期ループの中で実行するので、追加の作業は必要ありません。しかし、Django プロジェクトで完全な非同期テストを書きたい場合、いくつかの点を考慮する必要があります。まず、テストはテストクラスの `async def` メソッドでなければなりません (非同期コンテキストを与えるため)。Django は自動的に `async def` テストを検出し、独自のイベントループで実行されるようにラップします。非同期関数からテストする場合は、非同期テストクライアントも使用する必要があります。これは `django.test.AsyncClient` として、あるいは任意のテスト上で `self.async_client` として利用できます。 #### `class AsyncClient(enforce_csrf_checks=False, raise_request_exception=True, * (Keyword-only parameters separator (PEP 3102)), headers=None, query_params=None, **defaults)` `AsyncClient` は同期 (通常の) テストクライアントと同じメソッドとシグネチャを持ちますが、以下の例外があります。 - 初期化では、 `defaults` にある任意のキーワード引数が直接 ASGI スコープに追加されます。 - キーワード引数 `extra` として渡されるヘッダには、同期クライアントが必要とする `HTTP_` プレフィックスを付けてはいけません ([`Client.get()`](#django.test.Client.get) を参照してください)。例えば、HTTPの `Accept` ヘッダを設定する方法を示します。 ```pycon >>> c = AsyncClient() >>> c.get("/customers/details/", {"name": "fred", "age": 7}, ACCEPT="application/json") ``` > **Changed in Django 5.1** > > `query_params` 引数が追加されました。 `AsyncClient` を使用する場合、リクエストを行うあらゆるメソッドは await にする必要があります。 ``` async def test_my_thing(self): response = await self.async_client.get("/some-url/") self.assertEqual(response.status_code, 200) ``` 非同期クライアントは同期ビューを呼び出すこともできます。Django の [非同期のリクエスト経路](/ja/5.2/topics/async/) を通して実行され、両方に対応しています。`AsyncClient` を通して呼び出されたビューは、通常のクライアントが作成する `WSGIRequest` ではなく、`ASGIRequest` オブジェクトを `request` として取得します。 > **Warning** > > テストデコレータを使う場合、正しく動作するためには非同期対応でなければなりません。Django のビルトインデコレータは正しく動作しますが、サードパーティ製のデコレータは実行されないように見えるかもしれません (実行フローの間違った部分を「ラップ」してしまい、あなたのテストは実行されません)。 > > これらのデコレータを使用する必要がある場合は、テストメソッドをそれらの *内部で* [`async_to_sync()`](/ja/5.2/topics/async/#asgiref.sync.async_to_sync) でデコレートするべきです。 > > ``` > from asgiref.sync import async_to_sync > from django.test import TestCase > > > class MyTests(TestCase): > @mock.patch(...) > @async_to_sync > async def test_my_thing(self): ... > ``` ## メールサービス Django のビューのどれかが [Django のメール機能](/ja/5.2/topics/email/) を使ってメールを送信している場合、そのビューを使ってテストを実行するたびにメールを送信したくないでしょう。このため、Django のテストランナーは、Django が送信したメールを自動的にダミーの送信トレイにリダイレクトします。これにより、実際にメールを送信することなく、メール送信のあらゆる側面 (メッセージの送信数から各メッセージの内容まで) をテストできます。テストランナーは、通常のメールバックエンドをテスト用バックエンドに透過的に置き換えることでこれを実現します。(心配しないでください。これは Django 以外のメール送信者、例えばあなたのマシンのメールサーバを動かしているのであれば、それには影響しません。) #### `django.core.mail.outbox` テスト実行中、各送信メールは `django.core.mail.outbox` に保存されます。これは送信された全ての [`EmailMessage`](/ja/5.2/topics/email/#django.core.mail.EmailMessage) インスタンスのリストです。`outbox` 属性は、`locmem` メールバックエンドを使用した場合に *のみ* 作成される特別な属性です。通常は [`django.core.mail`](/ja/5.2/topics/email/#module-django.core.mail) モジュールの一部として存在しないので、直接インポートすることはできません。以下のコードでこの属性に正しくアクセスする方法を示しています。以下は `django.core.mail.outbox` の長さと内容を調べるテスト例です。 ``` from django.core import mail from django.test import TestCase class EmailTest(TestCase): def test_send_email(self): # Send message. mail.send_mail( "Subject here", "Here is the message.", "from@example.com", ["to@example.com"], fail_silently=False, ) # Test that one message has been sent. self.assertEqual(len(mail.outbox), 1) # Verify that the subject of the first message is correct. self.assertEqual(mail.outbox[0].subject, "Subject here") ``` [前述の](#emptying-test-outbox) ように、テストの送信トレイは Django `*TestCase` の各テストの開始時に空になります。手動で送信トレイを空にするには、`mail.outbox` に空のリストを代入してください。 ``` from django.core import mail # Empty the test outbox mail.outbox = [] ``` ## 管理コマンド管理コマンドは、[`call_command()`](/ja/5.2/ref/django-admin/#django.core.management.call_command) 関数を使用してテストできます。以下のように、出力は `StringIO` インスタンスにリダイレクトできます。 ``` from io import StringIO from django.core.management import call_command from django.test import TestCase class ClosepollTest(TestCase): def test_command_output(self): out = StringIO() call_command("closepoll", poll_ids=[1], stdout=out) self.assertIn('Successfully closed poll "1"', out.getvalue()) ``` ## テストのスキップ unittest ライブラリは [`@skipIf`](https://docs.python.org/3/library/unittest.html#unittest.skipIf) デコレータと [`@skipUnless`](https://docs.python.org/3/library/unittest.html#unittest.skipUnless) デコレータを提供しており、特定の条件下でテストが失敗することがわかっている場合にテストをスキップできます。例えば、テストを成功させるために特定のオプションライブラリが必要な場合に、テストケースを [`@skipIf`](https://docs.python.org/3/library/unittest.html#unittest.skipIf) でデコレートすることができます。そうすると、テストランナーはテストを失敗させたり完全に省略したりする代わりに、テストが実行されなかったこととその理由を報告します。これらのテストスキップ動作を補うために、 Django はさらに 2 つのスキップデコレータを提供しています。一般的な真偽値をテストする代わりに、これらのデコレータはデータベースの機能をチェックし、データベースが特定の機能をサポートしていなければテストをスキップします。デコレータは、データベース機能を表す文字列識別子を使用します。この文字列はデータベース接続の features クラスの属性に対応します。 [django.db.backends.base.features.BaseDatabaseFeatures クラス](https://github.com/django/django/blob/stable/5.2.x/django/db/backends/base/features.py) に、テストをスキップするベースとして使用できるデータベース機能の完全なリストがあります。 #### `skipIfDBFeature(*feature_name_strings)` 指定したデータベース機能がすべてサポートされている場合は、デコレートされたテストや `TestCase` をスキップします。例えば、データベースがトランザクションをサポートしている場合、以下のテストは実行されません (例えば、PostgreSQLでは実行 *されません* が、MyISAMテーブルを持つMySQLでは実行されます)。 ``` class MyTests(TestCase): @skipIfDBFeature("supports_transactions") def test_transaction_behavior(self): # ... conditional test code pass ``` #### `skipUnlessDBFeature(*feature_name_strings)` 指定したデータベース機能がサポートされていない場合は、デコレートされたテストや `TestCase` をスキップします。例えば、以下のテストはデータベースがトランザクションをサポートしている場合だけ実行されます (たとえば、PostgreSQLでは実行されますが、MyISAMテーブルを持つMySQLでは実行 *されません*)。 ``` class MyTests(TestCase): @skipUnlessDBFeature("supports_transactions") def test_transaction_behavior(self): # ... conditional test code pass ```