e2e testing framework at merpay TechTalk

1. 柴田芳樹/Yoshiki Shibata
Software Engineer@merpay
2021年1月27日
e2eテストフレームワーク

2. 自己紹介
柴田 芳樹（Yoshiki Shibata) 1959年11月生まれ
九州工業大学 情報工学科＆大学院（情報工学）
職務経歴
● 富士ゼロックス（株）（Xerox PARCを含め米国ゼロックス社に4年半駐在）
● 日本オラクル（株）
● （株）ジャストシステム
● 富士ゼロックス情報システム（株）（米国ゼロックス社に半年駐在）
● （株）リコー
● ソラミツ（株）
● （株）メルペイ（2018年6月～現在）
主な著書および翻訳本
● 『プログラマー”まだまだ”現役続行』
● 『Effective Java 第3版』
● 『プログラミング言語Go』
● 『ベタープログラマ』

3. e2eテストフレームワーク
（初めての）ウェブサービス開発@メルペイを通して

4. マイクロサービスの構成（簡易版）@メルペイ
iOS
アプリケーション
Android
アプリケーション
ブラウザー
アプリケーション
gateway
APIマイクロサービス 加盟店管理用API
マイクロサービス
・・・・・・・
マイクロサービスA マイクロサービスB マイクロサービスX
・・・
Google Kubernetes Engine / Google Cloud Platform

5. 開発の基本フロー（テストファースト開発）
API仕様の記述
e2eテストフレームワークの作成
テストコード作成
機能実装
リファクタリング
課題：
● 多くのマイクロ
サービスの開発が
同時並行に行わ
れた
● 依存するマイクロ
サービスに実際に
接続することなく
機能実装とテスト
を完了させる

6. API仕様に求められる内容
どのようなAPI仕様であっても、そこに記述されなければならない事柄は基本的に同じです。
● 提供される機能の説明
● 関数呼び出し、メソッド呼び出し、あるいは、RPC呼び出しでの
パラメータの意味と正当
な値の範囲
● 呼び出されるための事前の状態に何らかの制約があったり、呼び出し順序に何らかの
制約があったりするのであれば、どのような制約なのか
そして、防御的プログラミング（defensive programming）の観点から、以下の事柄もきちんと
仕様に記述されている必要があります。
1. 不正なパラメータ値が渡された場合、どのようなエラーが返される（あるいは例外がス
ローされる）のか
2. 不正な状態や不正な順序で呼び出された場合、どのようなエラーが返される（あるい
は例外がスローされる）のか
「gRPCを用いたマイクロサービスの API仕様の記述」（https://tech.mercari.com/entry/2019/05/31/040000）より

7. gPRC：.protoファイルにAPI仕様を記述
/**
* `Greeter` service provides a way to say a greeting message to a user and
* returns a message from the user.
* - Each RPC may return `Internal` but it is not listed in the `[ERRORS]` section for brevity.
*/
service Greeter {
// Sends a greeting message to a user and returns a message from the user.
rpc SayHello (HelloRequest) returns (HelloResponse) {}
}
/**
* `Hello` sends say a hello message to a user and returns a message from
* the user.
* - the returned message may be empty.
*
* [ERRORS]
* - InvalidArgument:
* - `name` is empty or too long
* - NotFound:
* - the user specified by `name` is not found in the system
*/
message HelloRequest {
string name = 1;
}
message HelloResponse {
string message = 1;
}
サービスの説明
RPCの簡単な説明
RPCの詳細な説明
エラーの説明

8. 書きたいテスト（１）
依存マイクロサービスへの ごとに、
返すレスポンスあるいはエラーの設定。
（スタブ設定）
テスト対象マイクロサービスの
呼び出し。
呼び出した結果の検査。
テスト対象
マイクロサービス
テストコード
依存マイクロサービス
（スタブ設定）
① スタブとしてのRPCの
振舞いの設定
② RPC呼び出し
⑤ RPC結果検証
③ RPC
呼び出し
④ テストコード
で指定されたレ
スポンスあるい
はエラー
【用語解説】スタブ（stub）とは、テスト対象モジュールを動作さ
せるために、依存先モジュールの振舞いをするもの

9. 書きたいテスト（２）
依存マイクロサービスの ごとに返す
レスポンスあるいエラーの設定。
ごとに渡されたパラメータを保存する設定。
（モックとして設定）
テスト対象マイクロサービスの 呼び出し。
呼び出し結果の検査。
依存マイクロサービスの へ正しくパラメータ
が渡されたかを検査。
テスト対象
マイクロサービス
テストコード
依存マイクロサービス
（スタブ/モック設定）
① スタブとしてのRPCの
振舞いの設定およびパラ
メータの保存の設定
⑥ ③のパラメータの確認
② RPC呼び出し
⑤ RPC結果検証
③ RPC
呼び出し
④ テストコード
で指定されたレ
スポンスあるい
はエラー
【用語解説】モック（mock）は、テスト対象先モジュールが、依存
先（モック）に期待通りの指示や出力を行ったかを検証するため
の機構を提供する
【用語解説】スタブとモックを区別せずにフェイク（fake）と呼ぶ場
合もある

10. e2eテストフレームワークの構築（概要）
テスト対象
マイクロサービス Test Suite
マイクロサービスA Fake
マイクロサービスB Fake
マイクロサービスX Fake
① RPCごとにレスポンス
/エラー設定
② RPC呼び出し
③ RPC呼び出し
テスト対象マイクロサービスは、別プ
ロセスとして起動
● 依存マイクロサービスは、起動時
に環境変数の設定によりTest
Suiteのプロセスへ接続するように
なっている

11. e2eテストフレームワークの構築（テスト開始/終了の同期）
テスト対象
マイクロサービス
Test Suite
依存マイクロサービスFakeの準備
テスト実施
サービス起動
サービスReady通知
サービス終了指示
サービス終了通知
テスト対象マイクロ
サービスが終了す
るとカバレッジ情報
を保存する

12. e2eテストフレームワークの構築（外部サービスのFake）
メルペイのマイクロサービス以外の依存している外部サービスも
Fakeする
● APIが公開されていることが多い。Go言語用ライブラリであれば、アクセスするためのソース
コードも調べることができるので、独自に
Fakeするのは難しくはない。
● テスト対象マイクロサービスから
外部サービスのAPIが正しく呼び出されたかをテストコードで
検査する
● GCPのPubSubのPublisher/Subscriber（gRPC）
○ Go言語用ライブラリ（cloud.google.com/go/pubsub）の場合、環境変数
PUBSUB_EMULATOR_HOST に接続先を設定する
● zendesk.com（APIが公開されている）
● Slack （github.com/nlopes/slack パッケージの場合、slack.APIURLに接続先を設定す
る）
● Google Drive （APIが公開されている）
ただし、外部DB（GoogleのSpannerなど）はFakeせずにそのまま利用

13. e2eテストフレームワーク（共通リポジトリ化）
複数のマイクロサービスの経験に基づいて、共通リポジトリ化しており、基本的に以下
の機能から構成される
● 各マイクロサービスのFakeサーバーの自動生成されたコード
● Fakeサーバーをスタブあるいはモックとして使用するためのAPI群
● テスト対象マイクロサービスを起動するAPI
● テスト対象マイクロサービスを終了するAPI
● 外部サービス（GCPのPubSubなど）のFakeサーバー
● 実行フロー制御ロガーAPI

14. 実行フロー制御ロガーAPI
ゴルーチンのスケジューリング次第で発生する不具合を再現するために、ゴルー
チンの実行順序をテストコード側から制御して、意図したタイミングで処理を実行さ
せる機構。
● NetBeansが提供している単体テスト用ライブラリを模倣し、e2eテストフレーム
ワークでも使えるように実装したもの
● NetBeansのAPIの詳細は、『APIデザインの極意』の「11.3.8 ロギングを使用
する実行フロー制御」を参照
Jaroslav Tulach著、『APIデザインの極意』
インプレスジャパン、2014年

15. e2eテストフレームワークの特徴
長所
● テスト対象マイクロサービスを、そのまま別プロセスとして起動する
○ 本番用のコードをそのまま動作させる
○ テスト対象マイクロサービスの内部構造に依存しない：
リファクタリングしやすい
○ 依存しているマイクロサービスが返すレスポンス/エラーをすべて網羅したテストが容
易に書ける
短所
● ある程度ホワイトボックステストになってしまう
○ テスト対象マイクロサービスのRPCを呼び出したときに、
依存しているマイクロサービス
に発行するRPCが何であるか知っている必要がある
○ 純粋にブラックボックステストとして書けるのは、依存しているマイクロサービスを全く
呼び出さない処理だけとなる

16. テストファースト開発（red-green-refactor）
● 新規機能開発
○ （「API仕様作成」→）「テスト作成」→「テスト不合格」→「実装」→「テスト合格」→「リ
ファクタリング」
○ 実際には、このサイクルをエラーケース、正常ケースと行う
● 機能修正
○ （「API仕様修正」→）「テスト作成あるいは修正」→「テスト不合格」→「実装」→「テ
スト合格」→「リファクタリング」
● バグ修正
○ （「原因調査」→）「再現テスト作成」（「再現テスト不合格」）→「修正・実装」→「再現
テスト合格」→「リファクタリング」

17. 関連資料
● 「gRPCを用いたマイクロサービスのAPI仕様の記述」
（https://tech.mercari.com/entry/2019/05/31/040000）
● 『API設計の基礎』（https://yoshikishibata.github.io/pdfs/apibasics.pdf）
● 「テスト駆動開発の経験」（ブログ記事）（
https://yshibata.blog.ss-blog.jp/2019-01-23）
● 「テストファースト開発」（ブログ記事）（
https://yshibata.blog.ss-blog.jp/2019-10-18）
● 「バグの修正の前に再現テストを先に書く」（ブログ記事）
（https://yshibata.blog.ss-blog.jp/2019-10-25）
● 「私が経験したソフトウェアテスト～ワークステーション、組み込みシステム、ウェブサービス
～」（JaSST ‘19 Tokai 特別講演）
（http://www.jasst.jp/symposium/jasst19tokai/pdf/S4.pdf）

18. ご清聴ありがとうございました
Thank you for your time and attention.
yoshiki.shibata@mercari.com
https://yshibata.blog.ss-blog.jp
https://twitter.com/yoshiki_shibata