契約に動的な値を提供するにはどうすればよいですか ?

スタブに関連する最大の課題の 1 つは、スタブの再利用性です。広く使用できる場合にのみ、その目的を達成できます。リクエスト要素とレスポンス要素の値 (日付や ID など) がハードコードされているため、通常はこれが困難になります。次の JSON リクエストを考えてみましょう。

{
    "time" : "2016-10-10 20:10:15",
    "id" : "9febab1c-6f36-4a0b-88d6-3b6a6d81cd4a",
    "body" : "foo"
}

ここで、次の JSON レスポンスについて考えてみましょう。

{
    "time" : "2016-10-10 21:10:15",
    "id" : "c4231e1f-3ca9-48d3-b7e7-567d55f0d051",
    "body" : "bar"
}

システム内のクロックを変更するか、データプロバイダーのスタブ実装を提供することによって、time フィールドの適切な値 (このコンテンツはデータベースによって生成されると仮定します) を設定するのに必要な苦労を想像してみてください。同じことが id フィールドに関連します。UUID ジェネレーターのスタブ実装を作成することもできますが、それを行ってもあまり意味がありません。

コンシューマーとしては、任意の形式の時刻または任意の UUID に一致するリクエストを送信する必要があります。こうすることで、システムは通常どおり動作し、何もスタブすることなくデータを生成します。前述の JSON の場合、最も重要な部分は body フィールドであると仮定します。そこに焦点を当てて、他のフィールドとのマッチングを提供できます。つまり、スタブを次のように機能させたいとします。

{
    "time" : "SOMETHING THAT MATCHES TIME",
    "id" : "SOMETHING THAT MATCHES UUID",
    "body" : "foo"
}

レスポンスに関する限り、コンシューマーとしては、それに基づいて操作できる具体的な値が必要です。次の JSON は有効です。

{
    "time" : "2016-10-10 21:10:15",
    "id" : "c4231e1f-3ca9-48d3-b7e7-567d55f0d051",
    "body" : "bar"
}

前のセクションでは、契約からテストを生成しました。プロデューサーから見ると、状況は大きく異なります。提供された契約を解析し、テストでは実際のリクエストをエンドポイントに送信します。リクエストのプロデューサーの場合は、いかなるマッチングもできません。プロデューサーのバックエンドが動作できる具体的な値が必要です。次の JSON が有効になります。

{
    "time" : "2016-10-10 20:10:15",
    "id" : "9febab1c-6f36-4a0b-88d6-3b6a6d81cd4a",
    "body" : "foo"
}

一方、契約の有効性の観点からは、レスポンスには time または id の具体的な値が含まれている必要はありません。これらをプロデューサー側で生成するとします。繰り返しますが、常に同じ値を返すようにするには、多くのスタブ化を行う必要があります。そのため、プロデューサー側からは次のようなレスポンスが必要になる場合があります。

{
    "time" : "SOMETHING THAT MATCHES TIME",
    "id" : "SOMETHING THAT MATCHES UUID",
    "body" : "bar"
}

では、コンシューマーにマッチャーを提供し、プロデューサーに具体的な値を提供するにはどうすればよいでしょうか (また、別の機会にその逆も可能です)。Spring Cloud Contract を使用すると、動的な値を指定できます。つまり、コミュニケーションの両側で異なる可能性があります。

詳細については、"契約 DSL" セクションを参照してください。

JSON に関連する Groovy ドキュメント (英語) を読んで、リクエストとレスポンスの本文を適切に構成する方法を理解しましょう。