Androidの自動テスト戦略

Androidのテスト戦略ページの解説です。（個人的見解も含まれています）
https://developer.android.com/training/testing/fundamentals/strategies

1. Androidの自動テスト戦略 食べログ開発本部アプリ開発部 太田 定志 2025年2月26日（水） 1
2. 自己紹介 太田 定志（おおた さだし） • 2018年 株式会社カカクコム入社 • 食べログアプリ開発部 基盤チーム リーダー • 主にAndroidアプリを担当 • アーキテクチャの見直し、リファクタリング、OS/ライブラリのアップデー ト、リリースフローの最適化、CI/CDの改善、開発環境の整備、採用、チー ムビルディング などなど、、、 • X • sada(@sadashi_ota) • GitHub • @sadashi-ota • Qiita • sadashi 2 The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.
3. Androidの自動テスト戦略 3 Android テストドキュメント ちょっと前に新しくなっていました Test smarter, not harder: new testing strategies documentation
4. Androidの自動テスト戦略 4 テスト戦略のページについて 大事なところを解説したいと思います
5. テストコードはなぜ必要か？ 5 まずは冒頭 そもそもテストコードは なぜ必要なのでしょうか？ 品質向上 工数削減
6. テストコードはなぜ必要か？ 6 例えば、工数削減を目的にした場合 テストコードの作成・保守といったコストがかかる。 そのため、確かに工数は減ってるかもしれないけど、 思ったより効果が出てないという結果に、、、
7. テストコードはなぜ必要か？ 7 ソフトウェアは「ソフト」になるように考案されたものだ。マシン の振る舞いを簡単に変更する手段になることを目的としたものであ る。マシンの振る舞いを簡単に変更したくない時には、それを 「ハード」ウェアと呼んだ。 上記の目的を達成するには、ソフトウェアはソフトでなければいけ ない。つまり簡単に変更できなければいけない。 書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」 Robert C.Martin (著), 角 征典 (翻訳), 高木 正弘 (翻訳) 第１部 第２章 「アーキテクチャ」より引用
8. テストコードはなぜ必要か？ 8 要はソフトウェアは変化に 素早く対応できるべきだということ。 そのためには正しいか間違っているかを 素早く検知する必要がある。
9. テストコードはなぜ必要か？ 9 要はソフトウェアは変化に 素早く対応できるべきだということ。 そのためには正しいか間違っているかを 素早く検知する必要がある。 そのためのテストコード
10. テストコードはなぜ必要か？ 10 ブログの1文にも以下の説明があります Emphasis on developer productivity （開発者の生産性を重視） *Test smarter, not harder: new testing strategies documentation より引用
11. テストコードはなぜ必要か？ 11 テスト戦略ページ冒頭の一文 A good testing strategy lets you take advantage of automated testing to focus on an important benefit: developer productivity. （優れたテスト戦略では、自動テストを活用して、 重要なメリットである デベロッパーの生産性に集中できます。） *https://developer.android.com/training/testing/fundamentals/strategies より引用
12. Androidの自動テスト戦略 12 では、どのような戦略を取ると 良いのでしょうか？
13. Androidの自動テスト戦略 13 では、どのような戦略を取ると 良いのでしょうか？ テストピラミッド テストサイズでの分類
14. 14 テストピラミッド テストピラミッドという考え方は昔*から存在 していました。 これは自動テストの「理想のテストケース数 の比率」を視覚化したものです。 • 忠実度 • どれだけ本番環境に近いかという度合い • 決定性 • 毎回同じように安定して動くかという度合い * 書籍「Succeeding with Agile（Mike Cohn(著) 2009年出版）」にて Mike Cohn氏が提唱
15. 15 テストサイズでの分類 続いて「テストサイズ」という分類 書籍「Googleのソフトウェアエンジニアリング 持続可能なプログラミングを支える技術、文化、プロセス」 竹辺 靖昭 (監修), Titus Winters (編集), Tom Manshreck (編集), Hyrum Wright (編集), 久富木 隆一 (翻訳) 「11章 テスト概観 11.2 テストスイートを設計する」より引用 我々は、あらゆるテストケースについて、 ２つの別個の次元があるという結論に達した。 それは、規模（size）と範囲（scope）だ。 規模は、テストケースの実行に必要なリソースを指し、 メモリー、プロセス、時間等だ。 範囲は、検証している特定のコードパスを指す。
16. 16 テストサイズでの分類 サイズ 説明 Small 単一プロセス内で実行される Medium 単一マシン上で実行される Large 任意の好きな場所で実行される (Enormous) (Googleではこの区分も存在するらしい)
17. 17 テストサイズでの分類 サイズ 説明 Small 単一プロセス内で実行される Medium 単一マシン上で実行される Large 任意の好きな場所で実行される (Enormous) (Googleではこの区分も存在するらしい) Small Medium Large ネットワーク NG localhost OK ローカルDB NG OK OK Android OS NG OK OK マルチスレッド NG OK OK 外部システム NG NG OK Androidにおけるテストの例
18. 18 テストサイズでの分類 サイズ 説明 Small 単一プロセス内で実行される Medium 単一マシン上で実行される Large 任意の好きな場所で実行される (Enormous) (Googleではこの区分も存在するらしい) Small Medium Large ネットワーク NG localhost OK ローカルDB NG OK OK Android OS NG OK OK マルチスレッド NG OK OK 外部システム NG NG OK Androidにおけるテストの例
19. 19 テストサイズでの分類 昔のAndroidのテストドキュメントにあった図がこちら。 分類がUnit Tests / Integration Tests / UI Tests という分類でした。
20. 20 テストサイズでの分類 昔のAndroidのテストドキュメントにあった図がこちら。 分類がUnit Tests / Integration Tests / UI Tests という分類でした。 割と普通に感じるこの分類は 人によって解釈が異なるという 問題点があります。
21. テストサイズでの分類 21 例えば、Unit Tests テスト対象クラスとその依存クラスがある時、 依存クラスに対してどちらにするのが Unit Testsでしょうか？ • テストダブルを使う • 本物を使う https://martinfowler.com/articles/2021-test-shapes.html より引用
22. テストサイズでの分類 22 どっちが正しいという話ではなく、 極端に言うと派閥の違いだったりします。 • テストダブルを使う • ロンドン学派 • 本物を使う • デトロイト学派（古典派）
23. 23 テストサイズでの分類 また、システムによってはIntegration Testsで Smallな（単一プロセスで動く）テストを作ることもできます。 そういったこともあり、色々な比率の図がでてきました。 そこで、ブレない基準「テストサイズ」が登場しました。 E2E Integration Static Unit Integration Integrated Implementation Detail ピラミッド トロフィー ハニカム
24. Androidの自動テスト戦略 24 テストピラミッドの何がうれしいのか？ Smallなテストほど実行速度が速いため、 早期のフィードバックが可能になります。 そのため、各テストの一番最下層を検討*し、 構築することで、テスト戦略ページの 冒頭に記載の３つが可能になります。 • Catches issues as early as possible. • （問題をできるだけ早い段階で検出します。） • Executes quickly. • （迅速に実行されます。） • Provides clear indications when something needs to be fixed. • （修正が必要な場合に明確な指示を表示します。） *具体的なものは「Decide the test category」をご参照ください
25. まとめ 25 テストサイズでピラミッドを構築し、 それらを適切なタイミングで実行するように設計すると、 最適なタイミングでのフィードバックを得ることができます。 具体的には以下のような判断が即座にできるようになります。 • コードが正しいのか • マージしていいのか • リリースしていいのか こうすることで開発者は生産性に集中することができます。
26. 26 まとめ 信頼度の高いテストスイートを作り上げる継続的な努力 と投資は価値がある。 書籍「LeanとDevOpsの科学 テクノロジーの戦略的活用が組織変革を加速する」 Nicole Forsgren Ph.D. (著), Jez Humble (著), Gene Kim (著), 武舎広幸 (翻訳), 武舎るみ (翻訳) 第１部 第４章「4.4.2 テスト自動化」より引用 テストを良くしていきましょう！
27. Androidの自動テスト戦略 27 ちょっと前に弊社のブログで テスト戦略について書きました。 食べログAndroidアプリで やったことについて気になるという方は ぜひこちらを読んでいただければ。 食べログAndroidアプリの自動テスト戦略
28. 最後に 28 We are hiring！！！ カジュアル面談大歓迎ですのでお気軽にご連絡ください iOSエンジニア Androidエンジニア
29. ご清聴ありがとうございました 29 Android is a trademark of Google LLC. Kotlin is a registered trademark of the Kotlin Foundation. IOSは、Cisco の米国およびその他の国における商標または登録商標であり、ライセンスに基づき使用されています。