はじめに
仕事でTDDをしながら開発をしている際に開発が一通り終わった際に、これはCDCしたほうが良いなと先輩が言っており、CDCテストの内容について聞きました
そのときに、そのテストケースっていまあるテストで同じことしているし、なんのためにやってるんだろうと自分の中で理解するまでに時間がかかったので考え方についてまとめます
CDCテストとは
CDCはConsumer Driven Contract Testの略で、マイクロサービス間の連携のテストをするものになります
マイクロサービスでは複数のサービスが連携して最終的なシステムを構成しているため、全体E2Eがやりづらいことがあります。全体E2Eをやる場合はそれに関わるすべてのサービスを起動してテストする必要があります。
そこで、CDCでは単体テストのデータ(モック)を同じにすることで連携が正しくできることを確かめます
以下に簡単な例を載せます
ここではサービスAのテストとサービスBのテストがあるとします
どちらもid: 1をリクエストに渡してテストをしています
この場合に、サービスA -> サービスB -> DB(モック)と考えることができ、サービスAとサービスBのCDCができたことになります
ここで注意が必要なのは、どちらもリクエストでid: 1を渡していることです。
CDCでは同じリクエストをすべてのサービスのテストでやらないと、正しく連携ができているかは保証できません
疑問
ここまで話を聞いてある疑問が浮かびました
先程の例ですでにサービスAはTDDで実装が終わっており、以下のテストがありました
サービスAのテスト項目
- id:1を渡すとユーザーwatanabeの名前が返ってくる
- id:2を渡すとユーザーyamadaが返ってくる
- idを渡さないとユーザーが返ってこない
サービスBのテスト項目
- id:1を渡すとユーザーwatanabeのJSONが返ってくる
この場合、サービスAではid:1を渡すとユーザーwatanabeが返ってくる、サービスBではid:1を渡すとユーザーwatanabeのJSONが返ってくるで連携できているので、CDCをやる必要はないのではないかと思いました
どちらもid:1をリクエストに渡しているので連携してそうなのに、なぜわざわざ同じようなテストをCDCとして書くのかがなかなか理解できませんでした
CDCとしてテストを作成する理由
もしいまあるサービスAとサービスBのテストをCDCとする場合は、サービスBは
- id:2を渡すとユーザーyamadaが返ってくる
- idを渡さないとユーザーが返ってこない
に対応するテストを追加する必要があります。
そうしないと本当に連携したときに動く保証がありません
例えばサービスB --> DB(モック)のときにidがないときにそもそも例外エラーになるかもしれません
いまは2つのサービスですが、これがいくつかのサービスに連携していくと後ろに慣ればなるほどテストケースが膨大になっていきます
そこで、わざわざCDCテストとして別にディレクトリを作成してその中に、CDC用のテストを作成していました
おわりに
今回は教えてもらったことを自分なりにまとめてみました
CDCもどこまでやるかというのが悩ましいポイントですが、考え方を理解すると実装自体はほとんど同じなので簡単にできました
参考