Mais conteúdo relacionado Semelhante a pact-jvmではじめるコンシューマー駆動契約 (20) Mais de Hiroyuki Ohnaka (20) pact-jvmではじめるコンシューマー駆動契約1. #ccc_g11
Copyright 2017 Hiroyuki Onaka
この作品は クリエイティブ・コモンズ 表示 4.0 国際 ライセンスの下に提供されています。
pact-jvmではじめる
コンシューマー駆動契約
2017/4/24 JJUG ナイト・セミナー「テスティング特集」
大中浩行(@setoazusa)
9. #ccc_g11
Copyright 2017 Hiroyuki Onaka
「なんかモックだらけになるんですけど…」
By Matthew Black from London, UK (325000 Uploaded by oxyman)
[CC BY-SA 2.0 (http://creativecommons.org/licenses/by-sa/2.0)], via Wikimedia Commons
https://commons.wikimedia.org/wiki/File%3AMock_up_of_a_British_Rail_Class_325_cab_at_the_National_Railway_Museum.jpg
16. #ccc_g11
Copyright 2017 Hiroyuki Onaka
「ストーリーではなくジャーニーをテストする」
「これに対抗する最善の方法は、少数の中核となるジャー
ニーに焦点を絞ってシステム全体をテストする方法です。こ
の中核となるジャーニーで対象になっていない機能は、互い
に分離してサービスを分析するテストで対処する必要があり
ます。このジャーニーは相互に合意され、共同で所有される
必要があります。音楽専門店の例では、CD の注文、商品の
返品、新規顧客の作成といった(高価値な対話であり極めて
少数の)動作に焦点を絞るでしょう。」
Sam Newman(著) 佐藤直生(監訳)
「マイクロサービスアーキテクチャ」
20. #ccc_g11
Copyright 2017 Hiroyuki Onaka
「テスト自動化ピラミッド」
• テスト自動化のレイヤーを「UI」
「Service」「Unit」の3つに分類したもの。
• 「Service」に対するテストが、アプリケー
ションのインターフェスに対するテストを、
UI(ユーザーインターフェース)を迂回して実
行することが特徴。
21. #ccc_g11
Copyright 2017 Hiroyuki Onaka
マイクロサービスアーキテクチャーにおけるサー
ビステスト
• 外部に対するサービス呼び出しをモック化した
上で、個々のサービスの機能に対して、ユー
ザーインターフェースを迂回して実行する。
• ユニットテストよりも広い範囲をカバーするテ
ストを、エンドツーエンドのテストよりも安定
かつ高速に実行できる。
24. #ccc_g11
Copyright 2017 Hiroyuki Onaka
コンシューマー駆動契約
• クライアント(コンシューマー)がサービス(プ
ロバイダー)に対してどのような振る舞いを
期待するかを記述したファイル(エクスペク
テーション)を作成する。
• エクスペクテーションは、クライアントのビ
ルド上で作成される。
25. #ccc_g11
Copyright 2017 Hiroyuki Onaka
• サービスは、クライアントからエクスペク
テーションを受け取り、自らがエクスペク
テーションの通り振る舞うかを、サービスの
ビルドの中で検証する。
• エクスペクテーションを作成する過程と検証
する過程が、分割されていることが特徴。
30. #ccc_g11
Copyright 2017 Hiroyuki Onaka
• 動物園で飼育されている動物のモデルを返す
サービス
• そのサービスを使用して動物園の情報を扱うク
ライアント
• サンプルコードは以下にあります
https://github.com/azusa/pact-jvm-
example
46. #ccc_g11
Copyright 2017 Hiroyuki Onaka
検証の厳密さ
例えば、エクスペクテーションとしてレスポン
スがapplication/jsonというContent-Typeを返
すことを期待した場合。
サービス(プロバイダー)がapplication/json;
charset=uif-8というContent-Typeを返した場
合、機能的には等価だが検証には失敗する。
47. #ccc_g11
Copyright 2017 Hiroyuki Onaka
Provider Stateの扱い
エクスペクテーションの検証時には、プロバーダー
(サービス)のバックエンドのデータベースや、対向
先のサービスのモックをセットアップする必要があ
ります。
よって、クライアントのテストとサービスのテスト
が、テストデータの関係を通じて密結合することに
なります。
49. #ccc_g11
Copyright 2017 Hiroyuki Onaka
エクスペクテーションをサービス側で検証する
には、クライアントが作成したエクスペクテー
ションをサービス側に引き渡す必要があります。
• CIサーバーの成果物(Artifact)で引き渡す
• Pact Brokerを使用する
• https://github.com/bethesque/pact_broker
51. #ccc_g11
Copyright 2017 Hiroyuki Onaka
コンシューマー駆動契約の使いどころ
• 正直、悩ましい
• サービス側をリファクタリングした時に、クラ
イアント側でのテストなしでクライアントと
サービス側のインターフェースを検証できると
いうのはメリット
• だが、サービス間の依存関係がそれなりに複雑
でない場合は、オーバースペックではないのか
52. #ccc_g11
Copyright 2017 Hiroyuki Onaka
• 「テスト自動化ピラミッド」の考え方はコン
シューマー駆動契約を導入しなくても有効
• アプリケーションのレイヤーそれぞれにどの
ようなテストを書き、テストの網をはってリ
スクを潰して行くかを考えていく中で、コン
シューマー駆動契約の考え方も生きてくる。
54. #ccc_g11
Copyright 2017 Hiroyuki Onaka
情報源
• Pactのドキュメント
• https://docs.pact.io/
• 実践 Pact:マイクロサービス時代のテストツール
• http://techlife.cookpad.com/entry/2016/06/28/1642
47
• すいーとみゅーじっく vol.1 TDDってなんだ
• https://fieldnotes.booth.pm/items/484459
56. #ccc_g11
Copyright 2017 Hiroyuki Onaka
ありがとうございました!
• 大中浩行(Onaka,Hiroyuki)
• @setoazusa
• グロースエクスパートナーズ株式会社
アーキテクチャソリューション部
テクニカルリード
• http://hiroyuki.fieldnotes.jp/