契約テスト

テストダブルを使用する最も一般的なケースの一つは、外部サービスと通信している場合です。通常、このようなサービスは別のチームによって維持されており、ネットワークが遅かったり、信頼性が低かったり、場合によってはサービス自体が信頼できない可能性があります。そのため、テストダブルが便利であり、自身のテストが遅くなったり、信頼性が低くなるのを防ぎます。しかし、テストダブルに対してテストを行うと、テストダブルが実際に外部サービスを正確に表現しているのか、外部サービスが契約を変更した場合に何が起こるのかという疑問が常に生じます。

これに対処する良い方法は、テストダブルに対して独自のテストを実行し続けるだけでなく、定期的に別の契約テストを実行することです。これらのテストでは、テストダブルに対するすべての呼び出しが、外部サービスへの呼び出しと同じ結果を返すことを確認します。これらの契約テストのいずれかで失敗した場合、テストダブルを更新し、おそらくサービス契約の変更を考慮するためにコードを更新する必要があることを意味します。

これらのテストは、通常のデプロイパイプラインの一部として実行する必要はありません。通常のパイプラインはコードの変更のリズムに基づいていますが、これらのテストは外部サービスへの変更のリズムに基づいて行う必要があります。多くの場合、1日に1回実行するだけで十分です。

契約テストの失敗は、通常のテストの失敗と同じようにビルドを中断させる必要はありません。ただし、状況を再び一貫させるためのタスクをトリガーする必要があります。これには、テストとコードを更新して、外部サービスとの一貫性を取り戻すことが含まれる場合があります。同様に、変更について話し合い、変更が他のアプリケーションにどのように影響するかを警告するために、外部サービスの管理者との会話をトリガーすることになるでしょう。

この外部サービスサプライヤーとのコミュニケーションは、このサービスが本番アプリケーションの一部として使用されている場合はさらに重要です。このような場合、契約の変更により本番アプリケーションが破損し、緊急修正とサプライヤチームとの緊急の会話がトリガーされる可能性があります。

契約における予期しない中断の可能性を減らすために、コンシューマ駆動契約のアプローチに移行すると便利です。サプライヤーチームに契約テストのコピーを提供して、ビルドパイプラインの一部として実行できるようにすることで、これを促進できます。

このような外部サービスをテストする場合、通常は外部サービスのテストインスタンスに対して行うのが最適です。場合によっては、本番インスタンスを使用せざるを得ない場合があります。その場合は、サプライヤーに何が起こっているかを知らせるためにサプライヤーと話し合い、テストで何をするかについて特に注意する必要があります。

契約テストは、外部サービスコールの契約をチェックしますが、必ずしも正確なデータをチェックするわけではありません。多くの場合、スタブは特定の日付の時点での応答をスナップショットします。これは、実際のデータよりもデータの形式が重要であるためです。この場合、契約テストでは、実際のデータが変更された場合でも、形式が同じであることを確認する必要があります。

これらのテストダブルを構築する最良の方法の1つは、SelfInitializingFakeを使用することです。