django-test-data

Django テストデータ

低速な Django テストスイートの多くは、不要なデータの構築や、より小さな境界でテストできる動作に対してリクエストやデータベースの経路全体を実行することに時間を費やしています。このスキルを使って、代表的な統合テストを維持しながらセットアップコストを削減します。

リファクタリングのワークフロー

1. テスト対象の動作を把握します。

   • 最小限で有用な境界を特定します。関数、フォーム、モデルメソッド、ミドルウェア、コマンドヘルパー、ビュー、またはリクエスト経路全体が該当します。
   • 配線を検証する統合テストをいくつか残し、境界が明確な詳細なケースはユニットテストに移します。

2. 最も高速なテストの基底クラスを選びます。

   • SimpleTestCase：データベースアクセスはありません。
   • TestCase：ロールバックを伴う通常のデータベーステストです。
   • TransactionTestCase：コミット済みトランザクションの動作のみを対象とします。
   • LiveServerTestCase：ブラウザー／ライブサーバーのテストのみを対象とします。

3. 広範なフィクスチャデータを取り除きます。

   • 大きなフィクスチャファイルや、常にオブジェクトを作成する基底クラスは避けます。
   • 各テストまたはクラスに必要なデータだけを構築します。

4. ファクトリーを意図的に使います。

   • ドメインがシンプルな場合は、小さなファクトリー関数から始めます。
   • リレーションシップやバリエーションが繰り返し登場するようになったら、Factory Boy または Model Bakery を使います。

5. クラスレベルのデータを setUpTestData で共有します。

   • TestCase の複数のメソッドで再利用するデータベースオブジェクトには、setUpTestData() を使います。
   • メソッド間で共有されるインメモリオブジェクトの変更は避けます。

6. テストのセットアップとアサーションにおけるデータベースアクセスを最適化します。

   • セットアップ／クエリのコストがボトルネックの場合は、select_related、prefetch_related、または bulk_create を使います。
   • パフォーマンスが契約の一部であるホットパスでは、クエリ数をアサートします。

例と判断の詳細については、patterns.md をお読みください。

判断基準

• データベースが不要なテストには、SimpleTestCase を使います。
• データベースが必要なテストが一部だけの場合は、クラスを分けます。
• コミット済みトランザクションの動作が必要なテストでは、まず captureOnCommitCallbacks() または内側の atomic() で十分か確認します。
• 高コストなオブジェクトを多くのテストで共有する場合は、setUp ではなく setUpTestData を使います。
• フィクスチャファイルが理解しにくい、または時間とともに肥大化する場合は、ファクトリーに置き換えます。
• ハードコードされた自動インクリメント ID に依存するテストでは、reset_sequences=True を有効にするのではなく、アサーションを修正します。
• 1つの高コストな処理から生じる1つの動作を記述する場合は、アサーションをまとめます。

よくある間違い

• フォームのエラーを直接調べず、レンダリングされた HTML だけでフォームのバリデーションをテストする。
• 管理コマンドのビジネスロジックを handle() の中に残し、call_command() 経由でのテストを強いる。
• TransactionTestCase をデフォルトとして使う。
• 一部のサブクラスしか必要としないデータを基底の TestCase に置く。
• ファクトリーを使えば、すべてのテストで大規模なオブジェクトグラフを作成してよいと考える。
• setUpTestData で作成したオブジェクトを変更し、後続のテストにインメモリ状態を漏らす。

検証

リファクタリングを終える前に、以下を確認します。

• 以前の動作が適切なレベルで引き続きテストされている。
• 有用な場合は、データベースを使うテストと使わないテストが分けられている。
• 繰り返し行うセットアップは、コスト削減につながる場合に限り setUpTestData またはファクトリーに移されている。
• 関連するテストが個別に、またモジュール／クラスの一部として実行した場合にも合格する。