BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース マイクロサービスアプリケーションにコントラクトテストを使用する

マイクロサービスアプリケーションにコントラクトテストを使用する

ブックマーク

原文(投稿日:2019/02/21)へのリンク

マイクロサービスを使用する場合,サービス間の統合ポイントがバグの温床になる。コントラクトテスト(contract test)は,コンシューマが定義したコントラクトに基づいてテストを実施するテスト手法だ。マイクロサービスのワークフローに適しており,統合バグを殺してくれる - PortbaseのテスタであるMaarten Groeneweg氏は,European Testing Conference 2019でこのように主張した。

開発の主流は巨大なモノリスを離れ,マイクロサービスへと向かっている。複雑化を心配することなく,より早いペースのデリバリが可能になるからだ。マイクロサービスによって,各チームの自律的なリリースが可能になる。エンドツーエンドテストでは,マイクロサービスの目的が損なわれてしまう,とGroeneweg氏は主張する。この種のテストは時間を要し,複雑である上,運用への移行時には各チームが互いのテストに依存性を持つようになるのだ。

マイクロサービスに足を踏み入れると,統合ポイントの数が飛躍的に増える。その統合ポイントそれぞれに,何がしかのバグが含まれる可能性がある,とGreoeneweg氏は言う。特にサービスが別々のチームによって開発される場合には,(期待する)動作に関して,大小さまざまな誤解の生じるリスクが高くなる。

コントラクトテストは3つのステップからなる,とGroeneweg氏は説明する。

  1. APIのコンシューマの立場で"コントラクト"を記述する。コントラクトには,(APIの)プロバイダに対して何を期待するかが記述される。このコントラクトに基づいて,プロバイダのモックが生成される。
  2. コンシューマはプロバイダのモックを対象に,自身のアプリケーションをテストすることができる。
  3. コントラクトをプロバイダに提出すれば,現実の実装がコントラクトの期待にマッチしているか検証することが可能になる。

コントラクトテストが素晴らしいのは,これをマイクロサービスのワークフローに適した方法で行うことができる点にある,とGroeneweg氏は言う。ここで最も重要なのは,APIの利用するサービス(コンシューマ)とAPI自体(プロバイダ)の間のテストを分離することだ。これにより,お互いを必要とせずに,両方を運用環境に移行させることが可能になる。それぞれが異なるチームによってメンテナンスされている場合は,自律的なテストとリリースが可能になるため,特に有効だ。

コントラクトテストは統合バグのリスクを低減する手段だ,とGroeneweg氏は言う。しかも,他のインテグレーションテストよりはるかに短時間で実施できる。リードタイムを削減し,テストからのフィードバックの遅れによる時間の無駄を省く上で,これは非常に重要なことだ。

コントラクトはコンシューマが設計するので,コントラクトテストは,実使用の観点からより便利なインターフェースやAPIの実現も可能にする。

InfoQではEuropean Testing Conference 2019を取材すると共に,Maarten Groeneweg氏とコントラクトテストについて会話した。

InfoQ: コントラクトテストにはどのようなアンチパターンがありますか,また,それにはどう対処すればよいのでしょうか?

Maarten Groeneweg: コントラクトテストは,サービス間の統合リスクを軽減する上で,非常に優れたテスト形式です。しかしながら,他のあらゆるテストと同じように,実施が難しい場合もあります。コントラクトテストを導入したいと思う場合は,次の7つのアンチパターンに注意してください。

  1. コントラクトテストの素晴らしい点は,APIの利用者が自身の期待するものを書き下すことができることです。これにはプロバイダの開発者に対して,コンシューマの希望にベストフィットしたソリューション開発を促す効果があります。しかし,これがコンシューマ主導から,コンシューマ指示に変わる場合があるのです。
  2. 人のやり取りの代わりに,ツールを使用したいと思う場合があります。コントラクトテストにおいてもこれは同じです。しかし,十分な議論を対面で行うことよりも,コントラクトテストに対して機能要求をしたり,コントラクトテストの作成を強要することを優先するのは,よい考えではありません。
  3. テストを作成する場合には,適切なカバレッジを確保することが大切です。ハッピーフロー以外のテストを忘れないでください。結果を伴わない処理や認証の失敗はごく当たり前に発生することですが,失敗する可能性が高い典型的なシナリオです。
  4. コンシューマは,必要なものについてのみコントラクトを作成すべきです。アプリケーションに必要のないコントラクトの分野を使用してはなりません。これを守ることで,プロバイダには,自身のサービスを変更し,最適化するための余地がより多く生まれます。
  5. チーム間でコントラクトテストを行うためには,ある程度の調整が必要になります。参加を拒むチームがある場合,これは難しくなるかも知れません。例えば,テストに参加しないコンシューマがいる場合,変更がコンシューマにも影響を与えないかどうか,プロバイダがどうやって確認できますか?ですから,組織でコントラクトテストを導入する前に,各チームの同意が取れていることを確認してください。
  6. コントラクトテストは複雑だ,と不満を言う人がいるかも知れません。確かにそのとおりですが,止めてはいけません。エンドツーエンドテストがそうであるように,そもそも統合テストは複雑なのです ... また,テストが複雑になるということは,ソリューションが複雑過ぎるという兆候でもあります。
  7. すべての自動テストがそうであるように,コントラクトテストもデリバリパイプライン中で実行されるべきものです。実行を人手に頼りたいとは思わないでしょう。人は常に忘れる可能性があるからです。コントラクトテストをパイプラインに設定するのは,他のテストよりも少し煩雑かも知れません。コンシューマとプロバイダがそれぞれ自分のパイプラインを持っているので,テストが常に実施されることを保証するためのコミュニケーションが必要になります。これを忘れると痛い目に会いますから,始める前に,これについての資料を読んでおくとよいでしょう。

InfoQ: コンシューマ主導からコンシューマ指示に変わるというアンチパターンの話がありましたが,これはどのようなものなのでしょう?

Groeneweg: コンシューマがレスポンスのフィールドに,ある特定の組み合わせを要求している場合を例にしてみましょう。プロバイダチームとってこの特別な組み合わせは,複数のデータベースを参照する必要があるため,可能であるとしてもパフォーマンスが非常に悪くことから,実装が非常に難しいのです。コンシューマはまともな議論をする余地もなく,この特別なソリューションを押し付けようとします。このようなコントラクトはもはやコンシューマ主導ではなく,コンシューマが決めているのです。このソリューションはプロバイダチームに多くの時間と労力を使わせる上に,動作の極めて遅いソリューションが完成して,全員がフラストレーションを抱えることになります。この場合の正しいアプローチは,コントラクトで協力して,全員にとって最善のソリューションを探すことです。

InfoQ: コントラクトテストについてもっと詳しく知りたい場合は,どのようにすればよいでしょうか?

Groeneweg: コントラクトテストに関しては,インターネット上に優れたリソースがたくさんありますし,よい講演もいくつかあります。私はPACT(コントラクトテスト用ツール)の資料が気に入っています。コントラクトテスト全般を対象とする,優れた記事がたくさんあります。私のWebサイトである"contract testing"でも,有用なリンクをいくつか紹介しています。

この記事に星をつける

おすすめ度
スタイル

BT