Androidテスト基礎講義

Transcript

1. Androidテスト基礎講義 1
2. 登壇者情報 トニオ（@tonionagauzzi） Androidエンジニア 趣味はブログ 2
3. 目次 1. テストとは何か 1-1. ソフトウェアテストの定義 1-2. テストの目的と利点 2. なぜテストが必要か 2-1. 失敗事例から学ぶ 2-2. プロジェクトとプロダクトのテストの違い 3. ワークショップ「もし、テストが不十分だったら…」 3-1. テストが無いときの解答例（失敗例） 3-2. テストがあるときの解答例（成功例） 3
4. 目次 4. テストの種類 4-1. テストのスコープ 4-2. テストのサイズ 4-3. テストの分布 4-4. テストダブル 5. Androidでテストを作るには 5-1. Androidテストの実行場所 5-2. Androidテストのツール 4
5. 1. テストとは何か 5
6. 1-1. ソフトウェアテストの定義 ソフトウェアテストとは、ソフトウェアが期待通りに動作するかを検証するプロ セスである システムや機能が仕様や要件を満たしているかを確認する バグや欠陥を発見し、品質を保証するための活動 テストプロセスは、特定の活動における開発成果物がその活動の要件を満たして いるかどうか、そしてシステムおよび／またはソフトウェアが意図された用途と ユーザーニーズを満たしているかどうかを判定します。 IEEE 829-2008 より 6
7. 1-2. テストの目的と利点 欠陥の発見：早期にバグを見つけ、修正コストを削減 品質の保証：ソフトウェアが要求仕様を満たしていることを確認 リスクの低減：本番環境での問題発生を防止 信頼性の向上：継続的なテストによる安定したソフトウェアの提供 開発者の信頼：変更を加える際の安心感を提供 ドキュメントとしての役割：期待される動作を示す生きた仕様書 7
8. 2. なぜテストが必要か 8
9. 2-1. 失敗事例から学ぶ 個人的な話 「テスト無くていいじゃん！動いてるし！！」 → 環境の違いで重大バグ発生。ユーザー企業へ謝りに行った。 「機種ごとに違うんだ。新機種が出るたびに"手動"で検証しよう！」 → 莫大な費用と時間を費やした。 9
10. Googleウェブサーバーの物語 Googleウェブサーバーの規模と複雑性の膨張による生産性の劇的な低下 リリースはバグを含むようになり本番で初めて見つかることも 10
11. 2-2. プロジェクトのテストとプロダクトのテストの違い プロジェクト：明確な終わりがある、目標は成果物の納品 テストの主な目的は、納品を成功させること プロダクト：明確な終わりはない、目標はユーザー価値の最大化や持続すること テストの主な目的は、プロダクト継続におけるリスクを最小化すること 11
12. 3. ワークショップ「もし、テストが不十分だったら…」 12
13. 問1：晴れ、曇り、雨を取得できる"WeatherApp"を、雪に対応してください。 https://github.com/tonionagauzzi/WeatherApp 13
14. 3-1. テストが無いときの解答例（失敗例） 解答例 「雪のステータスコードに対応、文言も追加した。ヨシ！！」 そして、雪が降った。 雪のマークが出なかった！！ 14
15. 3-2. テストがあるときの解答例（成功例） 解答例 「雪のステータスコードに対応、文言も追加した。ヨシ！！」 でも、テストが通っていない… 「修正しよう！」 15
16. テストが通るようになった！ そして、雪が降った。 問題なく表示された！ 16
17. 4. テストの種類 17
18. 4-1. テストのスコープ ユニットテスト メソッドやクラスなどが対象 インテグレーションテスト 2つ以上のユニット間の統合部分が対象 E2Eテスト、UIテスト ユーザーシナリオや画面全体が対象 図：Android アプリのテストの基礎 18
19. 4-2. テストのサイズ 小規模 単一プロセス 中規模 単一マシン 大規模 制約なし 参考： 【t-wada】自動テストの「嘘」をなくし、望ましい比率に近づける方法 【Developer eXperience Day 2024 レポート】 19
20. 4-3. テストの分布 図：Test Automation Strategy Syllabus - ISTQB 問2：どれが最もバランスの取れたテスト配分でしょうか？ 横軸はテストの実行数。 20
21. ピラミッド型が良いといわれることが多いが、すべてに通じる正解はない ピラミッド型は、低コスト、高速、決定性が高い Googleなど多くの企業が採用する一般的な考え方 アイスクリームコーン型は、E2Eテストを多く実施できる テストのないレガシーシステムをリファクタリングする際に効果的 複雑なシステム間連携、マイクロサービスなどの分散システムではインテグレーシ ョンテストが増えることもある 最適なテスト分布は、プロジェクトの特性、チームの規模、技術スタック、リスク許 容度などによって異なる。 21
22. 4-4. テストダブル フェイク、モック、スタブ、スパイ、ダミー、シャドウ 詳細：Android でテストダブルを使用する Android公式はフェイクを強く推奨 詳細：Android アーキテクチャに関する推奨事項 フェイクは本物の実装と同様に振る舞う フレームワークを必要としない 書くのに労力はかかるが、修正の影響を受けやすいので保守に強い 忠実性の担保が大事 モックはフレームワークで本物を模倣して振る舞う 少ないコードで書けるが、修正の影響を受けにくいので保守に弱い 22
23. 5. Androidでテストを作るには 23
24. 5-1. Androidテストの実行場所 開発マシン、Androidでないサーバー ローカルテストに向いている 小〜中規模テストに向いている 実行速度と決定性が高い 実機、エミュレーター インストルメンテーションテス ト、E2Eテストに向いている 中〜大規模テストに向いている 忠実性が高い 24
25. 5-2. Androidテストのツール JUnit4：Javaベースの標準的なテストフレームワーク AndroidJUnitRunner：Androidデバイス上でJUnitテストを実行するランナー JUnit Rules：テストの開始/終了処理を共通化できる Robolectric：実機を使わずAndroidコンポーネントをテストできる Compose UIテスト：Jetpack Composeで構築されたUIをテストできる Espresso：AndroidアプリのUIと操作をテストできる UI Automator：AndroidアプリのUIと操作をテストできる（他アプリも操作可能） Screenshot Testing：UIの変化の有無を自動で検出できる MockK：Kotlinのモッキングフレームワーク 25
26. さいごに 自動テストは、テストのタスク全てに適しているわけではない。 よく理解されている挙動を扱うために自動テストを用いると、人間のテスタ ーの高コストかつ定性的な労力を、人間のテスターが最大の価値を提供でき る製品部位に集中させることができる。 （ 『Googleのソフトウェアエンジニアリング』 、オライリージャパン、268- 269頁、2021年） 26
27. 補足：参考リンク Androidでアプリをテストする Android Studioでテストする Androidのテスト戦略 【動画】開発生産性の観点から考える自動テスト 27
28. 補足：テストを学べるおすすめ本5選 28