pact-jvmではじめるコンシューマー駆動契約

#ccc_g11
Copyright 2017 Hiroyuki Onaka
この作品はクリエイティブ・コモンズ表示 4.0 国際ライセンスの下に提供されています。
pact-jvmではじめる
コンシューマー駆動契約
2017/4/24 JJUG ナイト・セミナー「テスティング特集」
大中浩行(@setoazusa)

#ccc_g11
最近よく聞く話
• ユニットテスト
• 「このコンポーネントのテストモックだらけでわ
かりづらいんですけど…」
• エンドツーエンドのテスト
• 「テストケースが増えてきてメンテナンスがつら
いです…」

#ccc_g11
今日は、そんな自動テストに悩むみなさんへの
処方箋として、「コンシューマー駆動契約」に
ついてお話しします。

#ccc_g11
問題点の整理

#ccc_g11
モックか直接呼び出すか、それが問題

#ccc_g11
今までなら、モックを使うかどうかの判断は簡単
だった

#ccc_g11
「マイクロサービスアーキテクチャー」
By Paul Downey (CC-BY 2.0)
https://www.flickr.com/photos/psd/13109673843

#ccc_g11
複雑になるサービスの依存関係
BY Rose and Trev Clough(CC-BY SA 2.0) http://www.geograph.org.uk/photo/1490900

#ccc_g11
「なんかモックだらけになるんですけど…」
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

#ccc_g11
よろしい、ならばエンドツーエンドだ

#ccc_g11
エンドツーエンドテストつらい…
• データのセットアップつらい…
• 実行時間つらい…
• コード何もいじってないのにテスト落ちた、
つらい…
• 昔あった「結合一発勝負」とどう違うんや

#ccc_g11
• 各種パブリッククラウド上でのサービス構築
に代表されるように、テストを書くときに依
存するサービス/ミドルウェアが増えた。
• マイクロサービスアーキテクチャーがその流
れを加速している。

#ccc_g11
それにもかかわらず、テストをはじめとして開
発の方法論がいわゆる三層アーキテクチャーに
最適化されすぎているが故の問題。

#ccc_g11
ではどうするか

#ccc_g11
v
Sam Newman(著) 佐藤直生(監訳)
「マイクロサービスアーキテクチャ」

#ccc_g11
「ストーリーではなくジャーニーをテストする」
「これに対抗する最善の方法は、少数の中核となるジャー
ニーに焦点を絞ってシステム全体をテストする方法です。こ
の中核となるジャーニーで対象になっていない機能は、互い
に分離してサービスを分析するテストで対処する必要があり
ます。このジャーニーは相互に合意され、共同で所有される
必要があります。音楽専門店の例では、CD の注文、商品の
返品、新規顧客の作成といった（高価値な対話であり極めて
少数の）動作に焦点を絞るでしょう。」
Sam Newman(著) 佐藤直生(監訳)
「マイクロサービスアーキテクチャ」

#ccc_g11
「ストーリーではなくジャーニーをテストする」
どうやって…?

#ccc_g11

#ccc_g11
「テスト自動化ピラミッド」
Mike Cohn 「Suceeding with agile」

#ccc_g11
「テスト自動化ピラミッド」
• テスト自動化のレイヤーを「UI」
「Service」「Unit」の3つに分類したもの。
• 「Service」に対するテストが、アプリケー
ションのインターフェスに対するテストを、
UI(ユーザーインターフェース)を迂回して実
行することが特徴。

#ccc_g11
マイクロサービスアーキテクチャーにおけるサー
ビステスト
• 外部に対するサービス呼び出しをモック化した
上で、個々のサービスの機能に対して、ユー
ザーインターフェースを迂回して実行する。
• ユニットテストよりも広い範囲をカバーするテ
ストを、エンドツーエンドのテストよりも安定
かつ高速に実行できる。

#ccc_g11
• それでは、サービステストを実現する手段と
してのコンシューマー駆動契約とその実装で
あるpact-jvmについて見てみましょう。

#ccc_g11
コンシュー
マー駆動契約
とPact

#ccc_g11
コンシューマー駆動契約
• クライアント(コンシューマー)がサービス(プ
ロバイダー)に対してどのような振る舞いを
期待するかを記述したファイル(エクスペク
テーション)を作成する。
• エクスペクテーションは、クライアントのビ
ルド上で作成される。

#ccc_g11
• サービスは、クライアントからエクスペク
テーションを受け取り、自らがエクスペク
テーションの通り振る舞うかを、サービスの
ビルドの中で検証する。
• エクスペクテーションを作成する過程と検証
する過程が、分割されていることが特徴。

#ccc_g11
Pact
• オーストラリアのオンライン不動産サービス
RealEstate.com.auで開発された、コン
シューマー駆動契約を使用したテストツール
がオープンソース化されたもの。
• https://docs.pact.io/

#ccc_g11
• 当初はRubyで開発されていたが、その後他
の言語へも移植。
• エクスペクテーションがJSONで記述されて
いて、特定の言語からは独立したフォーマッ
トになっていることが特徴。

#ccc_g11
pact-jvm
• PactのJVM言語向け移植版
• https://github.com/DiUS/pact-jvm

#ccc_g11
サンプルの解
説

#ccc_g11
• 動物園で飼育されている動物のモデルを返す
サービス
• そのサービスを使用して動物園の情報を扱うク
ライアント
• サンプルコードは以下にあります
https://github.com/azusa/pact-jvm-
example

#ccc_g11
Animal Service
Consumer
(Zoo App)
Provider
(Animal Service)
Animal Service
Client

#ccc_g11
GET /animals/serval
{
"animals":
[
{"id": 1, "name": "サーバルちゃん"}
]
}

#ccc_g11
プロバイダーとしてのAnimal Service

#ccc_g11
エクスぺくてーションの出力
クライアントでテストを実行すると、
target¥pacts¥test_consumer-
test_provider.json に、JSONが出力されます。

#ccc_g11
サービス側のテスト
エクスペクテーション(先ほどのJSON)をコン
シュマー(クライアント)から受け取って、プロ
バイダー(サービス)のビルドで、サービスの振
る舞いを検証します。

#ccc_g11
エクスペクテーションとの
マッピング
アプリケーションの起動
テスト対象のポートの指定

#ccc_g11
実行結果

#ccc_g11
コンシュー
マー駆動契約
のポイント

#ccc_g11
コンシューマー駆動契約のポイント
• 検証の厳密さ
• Provider Stateの扱い
• エクスペクテーションの引き渡し

#ccc_g11
検証の厳密さ
例えば、エクスペクテーションとしてレスポン
スがapplication/jsonというContent-Typeを返
すことを期待した場合。
サービス(プロバイダー)がapplication/json;
charset=uif-8というContent-Typeを返した場
合、機能的には等価だが検証には失敗する。

#ccc_g11
Provider Stateの扱い
エクスペクテーションの検証時には、プロバーダー
(サービス)のバックエンドのデータベースや、対向
先のサービスのモックをセットアップする必要があ
ります。
よって、クライアントのテストとサービスのテスト
が、テストデータの関係を通じて密結合することに
なります。

#ccc_g11
上記二つの理由により、クライアントとサービ
スの間のやりとりを全て検証するのではなく、
サービスのクライアントの契約として必要な部
分に検証を絞る必要があります。

#ccc_g11
エクスペクテーションをサービス側で検証する
には、クライアントが作成したエクスペクテー
ションをサービス側に引き渡す必要があります。
• CIサーバーの成果物(Artifact)で引き渡す
• Pact Brokerを使用する
• https://github.com/bethesque/pact_broker

#ccc_g11
まとめ

#ccc_g11
コンシューマー駆動契約の使いどころ
• 正直、悩ましい
• サービス側をリファクタリングした時に、クラ
イアント側でのテストなしでクライアントと
サービス側のインターフェースを検証できると
いうのはメリット
• だが、サービス間の依存関係がそれなりに複雑
でない場合は、オーバースペックではないのか

#ccc_g11
• 「テスト自動化ピラミッド」の考え方はコン
シューマー駆動契約を導入しなくても有効
• アプリケーションのレイヤーそれぞれにどの
ようなテストを書き、テストの網をはってリ
スクを潰して行くかを考えていく中で、コン
シューマー駆動契約の考え方も生きてくる。

#ccc_g11
まとめ
ユニットテストとエンドツーエンドテスト双方
を補完し、クライアントとサービス相互のイン
ターフェース仕様の検証に絞った使い方が出来
るかが、コンシューマー駆動契約を推進する上
でのポイントになります。

#ccc_g11
情報源
• 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

#ccc_g11
「Testing Java Microservices」
• 2017年夏出版予定
• http://www.manning.com/books/testing-
java-microservicess

#ccc_g11
ありがとうございました！
• 大中浩行(Onaka,Hiroyuki)
• @setoazusa
• グロースエクスパートナーズ株式会社
アーキテクチャソリューション部
テクニカルリード
• http://hiroyuki.fieldnotes.jp/

pact-jvmではじめるコンシューマー駆動契約

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to pact-jvmではじめるコンシューマー駆動契約

Similar to pact-jvmではじめるコンシューマー駆動契約 (20)

More from Hiroyuki Ohnaka

More from Hiroyuki Ohnaka (20)

pact-jvmではじめるコンシューマー駆動契約