django-targeted-mocking

Django の対象を絞ったモック

モックは、低速、不確定、外部依存、または実行が難しい境界でのみ使用します。広範囲にモックを使うとテストは速くなることがありますが、検証できる内容が減るため、フレームワークのヘルパーやインターフェースを検証できる代替手段を優先してください。

境界に関するワークフロー

1. モックが必要かどうかを判断します。

   • ローカルのドメインロジックには実際のコードを優先します。
   • 外部 HTTP、時刻、設定、出力／入力、高コストなサービスとの接点をモックします。

2. テスト対象のコードが依存関係を参照する場所にパッチを当てます。

   • テスト対象のモジュールが使用するインポート済みのシンボルにパッチを当てます。モジュールが元のライブラリのパスから参照している場合を除き、元のライブラリのパスにはパッチを当てないでください。

3. 目的に合ったツールを優先します。

   • 設定：override_settings、modify_settings、または pytest-django の settings フィクスチャ。
   • 出力：io.StringIO、pytest の capsys、またはコマンドのテストヘルパー。
   • HTTP：手書きのレスポンスには requests-mock、記録したレスポンスには VCR.py。
   • 時刻：可能であれば時刻をパラメーターとして渡します。それ以外の場合は time-machine など、時刻に特化したツールを使用します。

4. インターフェースを考慮したモックを作成します。

   • autospec=True、spec、spec_set、create_autospec、または小規模なフェイクオブジェクトを使用します。
   • インターフェースが重要な場合、素の Mock／MagicMock は避けてください。

5. 想定外の外部向け HTTP 通信を遮断します。

   • 通常のテスト実行では、テストが意図せずネットワークにアクセスした場合に失敗するようにします。

具体的なパターンについては、mocking-patterns.md を参照してください。

判断ルール

• django.conf.settings への直接代入ではなく、Django の設定ヘルパーを使用します。
• 必要な属性が少数の場合は、自作のフェイクまたは types.SimpleNamespace を優先します。
• 自分で制御する決定論的な API レスポンスには requests-mock を使用します。
• 実際に記録したレスポンスが有用で安全に保存できる場合は、VCR.py を使用します。
• CI では、カセットがない場合に記録するのではなく失敗するよう、VCR の記録モードを設定します。
• 実行環境全体で一貫して時刻をモックします。複数の datetime 関数に手作業でパッチを当てないでください。
• テストで動作を検証する対象のコンポーネントはモックしないでください。

よくある間違い

• 設定に直接パッチを当て、テスト間で状態を漏らしてしまう。
• タイプミスの属性や誤った呼び出しシグネチャも受け入れる、何でも受け付ける MagicMock オブジェクトを使用する。
• テストから実際の外部サービスへのアクセスを許してしまう。
• CI で VCR のカセットを記録する。
• ビューの内部ヘルパーを過度にモックし、リクエストの動作をテストできなくなる。
• 間違ったインポートパスにパッチを当て、モックが有効だと思い込む。

検証

完了する前に、以下を確認してください。

• 各モックには、境界に応じた明確な理由があります。
• インターフェースが重要なモックには、仕様またはフェイクを使用しています。
• 通常のテストスイートでは、想定外の外部向け HTTP 通信が遮断されています。
• 設定は Django または pytest のヘルパーによって自動的に復元されます。
• テストではモックの呼び出しだけでなく、動作も検証しています。