テストツール

Djangoは、テストを作成するときに役立つツールの小さなセットを提供します。

テストクライアント

テストクライアントは、ダミーのWebブラウザーとして機能するPythonクラスであり、ビューをテストし、Djangoを利用したアプリケーションとプログラムで対話できます。

テストクライアントでできることのいくつかは次のとおりです。

URLでGETおよびPOSTリクエストをシミュレートし、低レベルのHTTP（結果ヘッダーとステータスコード）からページコンテンツまで、すべての応答を観察します。
リダイレクトのチェーン（存在する場合）を確認し、各ステップでURLとステータスコードを確認します。
特定の値を含むテンプレートコンテキストを使用して、特定のリクエストが特定のDjangoテンプレートによってレンダリングされることをテストします。

テストクライアントは、 Selenium またはその他の「ブラウザ内」フレームワークの代わりになることを意図していないことに注意してください。 Djangoのテストクライアントは別の焦点を持っています。要するに：

Djangoのテストクライアントを使用して、正しいテンプレートがレンダリングされていること、およびテンプレートに正しいコンテキストデータが渡されていることを確認します。
Selenium などのブラウザー内フレームワークを使用して、レンダリングされた HTMLおよびWebページの動作、つまりJavaScript機能をテストします。 Djangoは、これらのフレームワークに特別なサポートも提供します。詳細については、 LiveServerTestCase のセクションを参照してください。

包括的なテストスイートでは、両方のテストタイプを組み合わせて使用する必要があります。

概要と簡単な例

テストクライアントを使用するには、django.test.Clientをインスタンス化し、Webページを取得します。

>>> 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'<!DOCTYPE html...'

この例が示すように、Pythonインタラクティブインタープリターのセッション内からClientをインスタンス化できます。

テストクライアントの動作に関するいくつかの重要な点に注意してください。

テストクライアントは、Webサーバーが実行されていることを必要としません。実際、Webサーバーがまったく実行されていなくても、問題なく実行されます。これは、HTTPのオーバーヘッドを回避し、Djangoフレームワークを直接処理するためです。これにより、単体テストをすばやく実行できます。
ページを取得するときは、ドメイン全体ではなく、URLのパスを指定することを忘れないでください。たとえば、これは正しいです。
```
>>> c.get('/login/')
```
これは正しくありません：
```
>>> c.get('https://www.example.com/login/')
```
テストクライアントは、Djangoプロジェクトを利用していないWebページを取得することはできません。他のWebページを取得する必要がある場合は、urllibなどのPython標準ライブラリモジュールを使用してください。
URLを解決するために、テストクライアントは：setting： `ROOT_URLCONF` 設定によってポイントされたURLconfを使用します。
上記の例はPythonインタラクティブインタープリターで機能しますが、テストクライアントの機能の一部、特にテンプレート関連の機能は、テストの実行中でのみ使用できます。

この理由は、Djangoのテストランナーが、特定のビューによってロードされたテンプレートを判別するために、少し黒魔術を実行するためです。この黒魔術（基本的にはメモリ内のDjangoのテンプレートシステムのパッチ）は、テストの実行中にのみ発生します。
デフォルトでは、テストクライアントはサイトによって実行されるCSRFチェックを無効にします。

何らかの理由で、テストクライアントにCSRFチェックを実行させたい必要がある場合は、CSRFチェックを実施するテストクライアントのインスタンスを作成できます。これを行うには、クライアントを構築するときにenforce_csrf_checks引数を渡します。
```
>>> from django.test import Client
>>> csrf_client = Client(enforce_csrf_checks=True)
```

リクエストする

django.test.Clientクラスを使用してリクエストを行います。

class Client(enforce_csrf_checks=False, json_encoder=DjangoJSONEncoder, **defaults)

構築時に引数は必要ありません。ただし、キーワード引数を使用して、いくつかのデフォルトヘッダーを指定できます。たとえば、これにより、各リクエストでUser-Agent HTTPヘッダーが送信されます。

>>> c = Client(HTTP_USER_AGENT='Mozilla/5.0')

get（）、 post（）などに渡されるextraキーワード引数の値。クラスコンストラクタに渡されるデフォルトよりも優先されます。

enforce_csrf_checks引数は、CSRF保護をテストするために使用できます（上記を参照）。

json_encoder引数を使用すると、 post（）で説明されているJSONシリアル化用のカスタムJSONエンコーダーを設定できます。

raise_request_exception引数を使用すると、要求中に発生した例外をテストでも発生させるかどうかを制御できます。デフォルトはTrueです。

Clientインスタンスを作成したら、次のいずれかのメソッドを呼び出すことができます。

get(path, data=None, follow=False, secure=False, **extra)

提供されたpathに対してGET要求を行い、Responseオブジェクトを返します。これについては以下で説明します。

dataディクショナリのキーと値のペアは、GETデータペイロードを作成するために使用されます。例えば：

>>> c = Client()
>>> c.get('/customers/details/', {'name': 'fred', 'age': 7})

…次と同等のGETリクエストの評価になります。

/customers/details/?name=fred&age=7

extraキーワードargumentsパラメーターを使用して、リクエストで送信されるヘッダーを指定できます。例えば：

>>> c = Client()
>>> c.get('/customers/details/', {'name': 'fred', 'age': 7},
...       HTTP_ACCEPT='application/json')

…HTTPヘッダーHTTP_ACCEPTを詳細ビューに送信します。これは、 django.http.HttpRequest.accepts（）メソッドを使用するコードパスをテストするための良い方法です。

CGI仕様

**extraを介して送信されるヘッダーは、 CGI 仕様に従う必要があります。たとえば、ブラウザからサーバーにHTTPリクエストで送信される別の「ホスト」ヘッダーをエミュレートする場合は、HTTP_HOSTとして渡す必要があります。

すでにURLエンコード形式のGET引数がある場合は、データ引数を使用する代わりにそのエンコードを使用できます。たとえば、前のGETリクエストは次のように提示することもできます。

>>> c = Client()
>>> c.get('/customers/details/?name=fred&age=7')

エンコードされたGETデータとデータ引数の両方を含むURLを指定すると、データ引数が優先されます。

followをTrueに設定すると、クライアントはすべてのリダイレクトに従い、redirect_chain属性が中間URLとステータスコードのタプルを含む応答オブジェクトに設定されます。

/next/にリダイレクトされたURL /redirect_me/、/final/にリダイレクトされたURLがある場合、次のように表示されます。

>>> response = c.get('/redirect_me/', follow=True)
>>> response.redirect_chain
[('http://testserver/next/', 302), ('http://testserver/final/', 302)]

secureをTrueに設定すると、クライアントはHTTPSリクエストをエミュレートします。

post(path, data=None, content_type=MULTIPART_CONTENT, follow=False, secure=False, **extra)

提供されたpathに対してPOSTリクエストを行い、Responseオブジェクトを返します。これについては以下で説明します。

dataディクショナリのキーと値のペアは、POSTデータを送信するために使用されます。例えば：

>>> c = Client()
>>> c.post('/login/', {'name': 'fred', 'passwd': 'secret'})

…次のURLへのPOSTリクエストが評価されます。

/login/

…このPOSTデータを使用して：

name=fred&passwd=secret

content_typeを application / json として指定した場合、dataは、dict、リスト、またはタプルの場合、json.dumps()を使用してシリアル化されます。シリアル化はデフォルトで DjangoJSONEncoder を使用して実行され、 Client にjson_encoder引数を指定することでオーバーライドできます。このシリアル化は、 put（）、 patch（）、および delete（）要求でも発生します。

他のcontent_typeを提供する場合（例： text / xml （XMLペイロードの場合））、dataの内容は、HTTP Content-Typeのcontent_typeを使用してPOSTリクエストでそのまま送信されます。ヘッダ。

content_typeの値を指定しない場合、dataの値は multipart / form-data のコンテンツタイプで送信されます。この場合、dataのキーと値のペアはマルチパートメッセージとしてエンコードされ、POSTデータペイロードの作成に使用されます。

特定のキーに複数の値を送信するには（たとえば、<select multiple>の選択を指定するには）、必要なキーのリストまたはタプルとして値を指定します。たとえば、このdataの値は、choicesという名前のフィールドに対して3つの選択された値を送信します。

{'choices': ('a', 'b', 'd')}

ファイルの送信は特殊なケースです。ファイルをPOSTするには、ファイルフィールド名をキーとして指定し、アップロードするファイルへのファイルハンドルを値として指定するだけです。例えば：

>>> c = Client()
>>> with open('wishlist.doc', 'rb') as fp:
...     c.post('/customers/wishes/', {'name': 'fred', 'attachment': fp})

（ここでのattachmentという名前は関係ありません。ファイル処理コードが予期する名前を使用してください。）

ファイルハンドルとして、ファイルのようなオブジェクト（StringIOやBytesIOなど）を指定することもできます。 ImageField にアップロードする場合、オブジェクトには validate_image_file_extension バリデーターを渡すname属性が必要です。例えば：

>>> from io import BytesIO
>>> img = BytesIO(b'mybinarydata')
>>> img.name = 'myimage.jpg'

複数のpost()呼び出しに同じファイルハンドルを使用する場合は、投稿間のファイルポインタを手動でリセットする必要があることに注意してください。これを行う最も簡単な方法は、上記のように、post()に提供された後、ファイルを手動で閉じることです。

また、データを読み取れる方法でファイルが開かれていることを確認する必要があります。ファイルに画像などのバイナリデータが含まれている場合は、rb（バイナリの読み取り）モードでファイルを開く必要があることを意味します。

extra引数は、 Client.get（）の場合と同じように機能します。

POSTでリクエストするURLにエンコードされたパラメータが含まれている場合、これらのパラメータはrequest.GETデータで利用できるようになります。たとえば、リクエストを行う場合：

>>> c.post('/login/?visitor=true', {'name': 'fred', 'passwd': 'secret'})

…このリクエストを処理するビューは、request.POSTに問い合わせてユーザー名とパスワードを取得し、request.GETに問い合わせてユーザーが訪問者であるかどうかを判断できます。

followをTrueに設定すると、クライアントはすべてのリダイレクトに従い、redirect_chain属性が中間URLとステータスコードのタプルを含む応答オブジェクトに設定されます。

secureをTrueに設定すると、クライアントはHTTPSリクエストをエミュレートします。

head(path, data=None, follow=False, secure=False, **extra): 指定されたpathに対してHEAD要求を行い、Responseオブジェクトを返します。このメソッドは、メッセージ本文を返さないことを除いて、follow、secure、およびextra引数を含め、 Client.get（）と同じように機能します。

options(path, data=, content_type='application/octet-stream', follow=False, secure=False, **extra)

指定されたpathに対してOPTIONS要求を行い、Responseオブジェクトを返します。 RESTfulインターフェースのテストに役立ちます。

dataを指定すると、リクエストの本文として使用され、Content-Typeヘッダーがcontent_typeに設定されます。