モックを適切に使ったテスト

* ソフトウェアテストにおける「モック」とは何か
* モックのメリット・デメリット
* モックの適切な使い方

Transcript

1. モックを 適切に使ったテスト
2. 自己紹介 Atsushi Okui (@blue32a_jp) ソフトウェアエンジニア / Webアプリケーション エンジニア / PHPer 関心：設計、コード品質、リファクタリング、テス ト、モデリング
3. 今回のテーマ • ソフトウェアテストにおける「モック」とは何か • モックのメリット・デメリット • モックの適切な使い方
4. ソフトウェアテストにおける 「モック」とは何か
5. 一般的な場面での「モック」 モック(Mock)／モックアップ(Mock)とは、 ”製品の外観の検討や機能の確認のためにつくられる原型。” – Wikipedia https://ja.wikipedia.org/wiki/木型
6. ソフトウェアテストにおける「モック」 ”モックとは、（略）、テスト対象システム（System Under Test: SUT）とその協力者オブ ジェクトのやり取りを検証するのに使われるテスト・ダブルのことです。” – 『単体テストの考え方/使い方』
7. テストダブル (Test Double) とは ”テストダブルとは、自動テストに使用する偽物、代用品のことです。たとえば、データ ベースや外部サービスの動作を模倣した偽物（テストダブル）を作り、自動テストから使 います。” – 第4回 テストダブル ～忠実性と決定性のトレードオフを理解する～ https://gihyo.jp/dev/serial/01/savanna-letter/0004 ※スタントマン/スタントダブル（Stunt Double）からきている。
8. テストダブルの５つの分類 • スタブ：テスト対象への間接入力を操作 • スパイ：テスト対象の間接出力の記録 • モック：テスト対象の間接出力の検証 • フェイク：間接入出力の検証以外の目的での置き換え • ダミー：テスト対象が要求しているがテストに影響与えない それぞれの詳しい説明はこちら👇 xUTPによるテストダブルの定義とその図解 https://engineers.ntt.com/entry/20251208_advent-calendar-day8/entry
9. 広義のモック、狭義のモック 広義のモック：テストダブル 狭義のモック：テストダブルの分類の一つであるモック — 『テスト駆動開発』 付録C 訳者解説
10. 複数の意味を持つ「モック」 ”「モック」という言葉は複数の意味があり、状況によっては異なる意味で使われることが あります。（略）、モックはテスト・ダブルの中の１つに過ぎないのですが、「モック」という 用語がすべてのテスト・ダブルに対して扱われる傾向があります。さらに「モック」はテス ト・ダブルの意味では用いられず、モック・ライブラリから提供されるモック・オブジェクトを 作成するためのクラスのことを意味することがあります。” – 『単体テストの考え方/使い方』
11. まとめ：ソフトウェアテストにおける「モック」とは • 多くは、自動テストで使用される代用品（テストダブル）のことを指す • 場合によっては、テストダブルの分類の１つであったり、テストダブルを作成するた めのツールを指していることもある • テストダブルは、用途によって５つに分類される この資料では、特別な場合を除いてモック＝テストダブルの意味で扱います。 「モック」が何を指すか分かったところで、次はモックを適切に扱うためにメリット・デメリッ トを確認していきます。
12. モックのメリット
13. メリット１：テストの実行速度が向上する 例えば次のような処理をモックに置き換えることで実行速度を向上させることが期待でき ます。 • ネットワーク通信や外部リソースを使用する処理 • 大きなデータを操作する処理
14. メリット２：テストの決定性が向上する 决定性とは、同じ入力に対しては常に同じ結果を返す性質です。次のような不安定な動 作をする処理をモックに置き換えることで、再現性のあるテストが実施できます。 • ネットワーク通信など何らかの理由で失敗することがある処理 • ランダム性のある処理 • 現在時刻を使用した処理
15. メリット３：テストしにくいものがテスト可能になる 次のような自動テストするのが難しい処理をテスト可能にすることができます。 • 本番以外で実行できない処理 • 例外系など再現が難しい処理 • 入力の制御や出力の観測が直接できない処理 ◦ メール送信など、結果が外部へ向かうために観測できないもの ◦ 設計に課題があり、直接制御できないもの（テスト容易性が低い）
16. モックのデメリット
17. デメリット１：テストコードが長くなる 代用品としての振る舞いを決めたり、テスト対象からの間接入力を検証したりなど、準備 フェーズのコードが長くなりがちになります。
18. デメリット２：検証（Assert）が分散する テストコードをAAAパターン(*1)で構成することで分かりやすくすることができますが、 モックを準備する段階に検証のコードが入りがちになります。 *1 準備（Arrange）、実行（Act）、検証（Assert）の３つのフェーズで構成する
19. デメリット３：テストが壊れやすくなる テスト対象が内部的に使う依存を制御するので、実装の詳細がテストに漏れ出ていきま す。これにより、振る舞いを変えずに実装を変えるリファクタリングするにはテストも変更 することになり、リファクタリングへの耐性(*1)が低下することになります。 *1 『良い単体テストの４本の柱』
20. デメリット４：本物の動きと同一である保証はない テストダブルの動作は開発者の想定で決めていくので、本物が同じように動く保証はあ りません。また本物の動作が変更された時、モックはその変更に追従してくれません。
21. デメリット５：テストしにくいものがテスト可能になる これはメリットでもありますが、デメリットでもあります。 「テストしにくい」という状態は設計に課題を抱えていることがあります。しかしながら、 モックライブラリがあまりに強力なため、本来であれば「設計を改善する」という選択を検 討したいところを「モックを使ってテストする」という方へ向かいがちになります。
22. モックの泥沼 ”ここで言うモックの泥沼とは、ユニットテストのコードがモックに埋め尽くされていまい、もともとのテストが ほとんど意味をなさなくなっている状態のことを指します。（略）。この泥沼の力は強大です。開発の効率を 上げてくれるはずだったテスト自体が逆にあなたを苦しめ、作業速度を落とします。雑多な情報が多すぎ て、テストで想定していた正しい動作がどんなものだったのかが、もはやわかりません。わかることはただ １つ、何か変更を加えようとすると、何かが壊れることだけです。そして設計を改善するのは苦行となり、誰 も改善をしなくなります。” – 『初めての自動テスト』
23. 経験談 最初にテストを自動化したときは、テストや設計に関する知見が少なく、それを補うかの ようにモックを使っていました。そんな中でこのような疑問が生まれました。 「テストは全てパスしたが、本番環境でも正しく動くだろうか？」 残念ながらこの疑問に自信を持って答えられる状況ではありませんでした。 テストには「どれだけやれば十分」といった正解はありません。抽象的ですが「テストの 結果に自信が持てるかどうか」が一つの指標になります。モックは便利なものですが、 対価として「テストへの自信」を支払うことになります。
24. まとめ：モックのメリット・デメリット • メリットは「テストの実行が容易になる」 • デメリットは「保守性やテストの信頼性が低下」 • 「テストしにくいものがテスト可能になる」は諸刃の剣 • モックを多く使うほど、自動テストの利点を失うことになる モックのメリット・デメリットが確認できたところで、最後にモックの適切な使い方を考えて いきます。
25. モックの適切な使い方
26. モックを使わずに済むなら、そのほうがいい 前のセクションで確認したように、モックにはメリットだけではなくデメリットもあります。 モックを使わずに課題を解決できるならそれに越したことはありません。 そこで、モックを利用することで得たいメリットについて、他の選択肢を考えていきましょ う。
27. １：テストの実行速度を向上させたい • テストの実行を並列化できないか • 遅いテストの実行タイミングを工夫できないか（テストのグループ化やスケジュール 実行） • 設計を改善し「遅い処理」への依存を減らせないか • コンテナ技術を活用し、外部依存を同じマシンで実行できないか
28. ２：テストの决定性を向上させたい 本物が不安定であることから、安定したモックへの代替以外の解決策としては次のよう なものになります。 • 設計を改善し「决定性が低い処理」への依存を減らせないか 例えば、ランダムな値を出力する乱数生成器に直接依存するのではなく、そこから生成 した値だけを使う形にするような構造を検討します。
29. ３：テストしにくいものをテストしたい • 本番と同等、または限りなく近い環境を用意できないか • 外から見える振る舞いだけでテストできないか • テストしやすい構造にできないか 前述の通り「テストしにくい」状態は設計に課題がある場合があります。そうした課題が ないか確認し、積極的に改善する方法を検討します。
30. テスト対象のシステムから「直接制御できない外部の依存」は有効な置き換え対象にな ります。「直接制御できない外部の依存」の具体的な例はメールサービスです。メール サービスに対するリクエストは観察することができますが、実際にメールを送信する過程 は観察することができません。 ”モックに置き換えるべき依存は管理化にない依存、つまり、外部アプリケーションから観 察可能な依存だけになります。” – 『単体テストの考え方/使い方』 モックへの置き換えが有効なもの
31. まとめ • 「モック」の多くは自動テストで使用される代用品（テストダブル）のことを指すが、テ ストダブルの分類の１つやモックライブラリなどのツールを指している場合もある • メリットは「テストの実行が容易になる」、デメリットは「保守性やテストの信頼性が低 下」 • 「テストしにくいものがテスト可能になる」はメリットであり、デメリットでもある • モックを多く使うほど、自動テストの利点を失うことになる • モックを使わずに解決する方法も検討する
32. How do you like Testing?
33. 完