@tatsuya6502 Forkwell主催 Rust ランチ LT 大 会 Pact による CDC テストに 入 門 してみた マイクロサービスの結合テストだって怖くない

本 日 の内容 1. CDCテストとは？（3分） 2. Pactの紹介（Rustコードと共に）（9分） 3. 次のステップ（1分） • Rustの話というより、テスト技法の話が中 心 • 駆け 足 で説明します。聞き逃したら以下をチェックしてください • スライド公開予定 • Forkwellの動画アーカイブ CDCテストを 支 援する「Pact」というツールがRustに正式対応していると聞いて試してみた。

自 己 紹介 • Fairy Devicesのソフトウエア技術者 • Webバックエンド（Rust） • 分析基盤 • インフラ（AWS、Kubernetes） • 中国上海 在住 • フルリモート勤務 • IT業界で35年以上のキャリアを有する • 以前はシリコンバレー企業に在籍（英語が公 用 語、リモート勤務） • Amazon S3 APIとIAM API互換の分散オブジェクトストアを開発していた • 高 機能でテストが 大 変。12年間の在籍中、 自 動テストの開発・維持に多くの時間を割いた Tatsuya Kawano @tatsuya6502 （共著、2019年） （共著、2012年）

CDCテストとは • サービス間連携のインターフェース（後述）を 高 精度かつ少ない労 力 でテストできる • 単に「契約テスト」とも呼ばれる • 2006年ごろから知られている？ • マーティン・ファウラー 氏 のBlikiにに掲載された記事 • Consumer-Driven Contracts: A Service Evolution Pattern, by Ian Robinson • https://martinfowler.com/articles/consumerDrivenContracts.html • 私は1年前にこの本で知った • Web APIテスト技法 • Mark Winteringham（原著）、 長 尾 高 弘（翻訳） • 翔泳社（Manning書籍の和訳） • ISBN 978-4-798182-95-7 コンシューマー駆動 契約テスト（Consumer Driven Contract Test）

• 近年のITシステムは、疎結合の複数のサービス（サブシステム）で構成される傾向にある • サービスAが正しく動作することをどうやってテストするか • 結合テスト（含：E2Eテスト） • サービスAのみ単体でテストする？ • サービスBとサービスCについてはモック等のテストダブルで代 用 する 複数サービスで構成されるシステムのテスト フロントエンド (SPA) サービスA バックエンド サービスB サービスC HTTP REST gRPC HTTP REST

• 前者（結合テスト、特にE2Eテスト）は避けたい • セットアップと維持が 面 倒 • 遅い • フレーキーなテスト（時々失敗するテスト）が発 生 しがち • 問題を発 見 できる時期が遅すぎることも （リリース直前とか） • できるだけ後者（サービス単体のテスト）にしたい • 懸念：テストダブルで想定している仕様と、本物との間に差異がないか？ • 思ってた仕様と違った • 相 手 側のバージョンアップに伴い仕様が変更された E2Eテスト vs サービス単体のテスト https://pact fl ow.io/blog/what-is-contract-testing/

CDCテストで補完する • CDCテストを 行 うことで、テストダブルが本物に 十 分近い ことが確認できる • CDC（コンシューマー駆動 契約テスト）の意味 • サービスの利 用 者のことをコンシューマーと呼ぶ • サービスの提供者はプロバイダー • コンシューマー駆動 • コンシューマーがインターフェース仕様（契約）を提 示 する • 契約にはインターフェースの「振る舞い」とメッセージの「構造」が書かれている • 契約が守られていることを、両者が個別に 自 動テストで検証する → 結合テストの代わりとなる • プロバイダーの仕様変更等で互換性の問題が起きても、すぐに発 見 できる CDCテストを併 用 することで、テストダブルの懸念を解消 プロバイダー （提供者） コンシューマー （利 用 者） コンシューマー （利 用 者） コンシューマー （利 用 者） 契約 この内容で お願いします サービスA サービスX サービスY サービスZ 契約 契約

• CDCテストを 支 援するOSSツール群 1. 契約の仕様を策定 • 英単語の pact の意味は、条約、協定 • JSON形式 • 最新はPact V4 speci fi cation 2. 自 動テストのためのツールとライブラリー https://pact.io/ 3. Pactブローカー • 契約やテスト結果等を管理するサービス • あれば便利 • セルフホスティング（公式のOSS版） • PactFlow https://pact fl ow.io/ • Pactの開発元による機能強化版

Pactライブラリーの 言 語対応状況 https://github.com/pact-foundation/ 言 語 GitHubリポジトリー スター数 (2024-10-21) リポジトリー作成 月 Ruby pact-ruby 2,166 2013-11 JavaScript pact-js 1,622 2016-06 JVM 言 語 pact-jvm 1,081 2014-01 Go pact-go 856 2016-05 .NET (C#) pact-net 843 2014-07 Python pact-python 573 2017-03 PHP pact-php 273 2017-07 Rust pact-reference 93 2016-02 C++ pact-cplusplus 9 2019-10 • 2014年 　 Ruby、JVM、.NET • 2016年 　 Rust、Go、JS • ツールのメイン 言 語を Ruby → Rustへ置き換え中 らしい • 現在はRustによる実装が リファレンス実装という 位置付けらしい • ScalaとSwiftは 非 公式の 実装あり

プロトコル対応 • HTTP RESTful • gRPC • 公式プラグインにてサポート • Kafka、Amazon SQSなどのメッセージング • やり取りされるメッセージの内容のみテストする • 個別のメッセージングプロトコルには対応しない

デモ https://docs.pact.io/implementation_guides/workshops 1. コントラクトテストの基本 ← 今回はここだけ 2. 認証を伴うAPIのテスト 3. Pactブローカーの利 用 • Rust版のワークショップはないので、 自 分で書いたコードで説明 • Ruby, JavaScript, Go, JVM (Maven, Junit5, Spring Boot), Android, .NET Pactワークショップに沿って基本を紹介

コンシューマー側でクライアントを実装（1/2） https://github.com/pact-foundation/pact-workshop-js/blob/step1/README.md#step-1---simple-consumer-calling-provider

コンシューマー側でクライアントを実装（2/2） https://github.com/pact-foundation/pact-workshop-js/blob/step1/README.md#step-1---simple-consumer-calling-provider

コンシューマー側で契約（Pact）を 生 成（1/4） https://github.com/pact-foundation/pact-workshop-js/tree/step3#step-3---pact-to-the-rescue Pact V3 マッチングルール

コンシューマー側で契約（Pact）を 生 成（2/4） Pact V3 マッチングルール

コンシューマー側で契約（Pact）を 生 成（3/4） https://github.com/pact-foundation/pact-workshop-js/tree/step3#step-3---pact-to-the-rescue

コンシューマー側で契約（Pact）を 生 成（4/4） https://github.com/pact-foundation/pact-workshop-js/tree/step3#step-3---pact-to-the-rescue

プロバイダー側の実装 https://github.com/pact-foundation/pact-workshop-js/tree/step4#step-4---verify-the-provider

プロバイダー側でPactを検証する（1/2） https://github.com/pact-foundation/pact-workshop-js/tree/step4#step-4---verify-the-provider

プロバイダー側でPactを検証する（2/2） https://github.com/pact-foundation/pact-workshop-js/tree/step4#step-4---verify-the-provider

Pactテストの拡充（1/2） https://github.com/pact-foundation/pact-workshop-js/blob/step1/README.md#step-1---simple-consumer-calling-provider

Pactテストの拡充（2/2） https://github.com/pact-foundation/pact-workshop-js/blob/step1/README.md#step-1---simple-consumer-calling-provider

プロバイダーステート（1/3） https://github.com/pact-foundation/pact-reference/blob/master/rust/pact_veri fi er_cli/README.md#state-change-requests

プロバイダーステート（2/3） https://github.com/pact-foundation/pact-workshop-js/tree/step7#step-7---adding-the-missing-states

プロバイダーステート（3/3） https://github.com/pact-foundation/pact-workshop-js/tree/step7#step-7---adding-the-missing-states

感想 • E2Eテストや結合テストを、サービス単体での機能テストと契約テストで置き換えていく • 効果が 見 込める場所の 見 極めが必要 • リリースサイクルが異なるコンシューマーとプロバイダー • PoCの時点では、 自 チーム内で完結してる 方 がやりやすい？ • 自 チームでコンシューマーとプロバイダーの両 方 を開発している • 一方 、契約テストが 高 い効果を発揮するのは、コンシューマーとプロバイダーが それぞれ別のチームによって開発されているとき 個 人 的にはPoC（お試し導 入 ）して、効果を測りたい

テスト範囲について コンシューマー側では、契約テストと機能テストを混同しないよう注意する https://pact fl ow.io/blog/ fi ve-reasons-why-your-contract-testing-initiative-could-fail-and-how-to-avoid-them/ 引 用 元：契約テストの導 入 に失敗する5つの理由（そして、その回避 方 法）

さらに詳しく • PactFlowのブログ • https://pact fl ow.io/blog/ • 契約テストとは何か？ なぜ試すべきなのか • 契約テストの導 入 に失敗する5つの理由（そして、その回避 方 法） • スキーマはコントラクトに 非 ず • スキーマの例：Open API (旧Swagger)、Protocol Bu ff ers、GraphQL • メッセージの構造を表現するためのものなので、振る舞いの表現は不 十 分 • E2Eテストが詐欺であることの証明 • E2Eテストがスケールしないことを数式で解説 • 本セッションのスライドはSpeaker Deckにて公開予定 • https://speakerdeck.com/tatsuya6502