Androidテスティング実践基礎編

Androidテスティング実践
①基礎編

本スライドは、NTTソフトウェア社内技術者育成研修（ソフト道場研修）テキストです。
【著作権・免責事項】
 本セミナーコースの内容、本資料のすべての著作権は、NTTソフトウェア株式会社に帰属します。
 無断での本資料の複写、複製、再利用、転載、転用を禁じます。
 本資料と演習等で利用するすべての教材は、NTTソフトウェア株式会社からの保証なしに提供されます。
 本書に記載されている会社名および製品名は、一般に各社の商標または登録商標です。
Copyright © 2016, NTT Software Corporation. 2
※ 演習問題に関するスライドは、一部を除き、本ファイルには含まれておりません。
また、演習に必要なソースコードも含まれておりません。ご了承ください。

本研修の対象者・受講条件
対象者
Androidアプリのユニットテスト自動化に興味があるが、
どこから手を付けて良いかわからない方
Androidのユニットテストを書き始めてみたが、様々な理由で
途中で諦めてしまった(または諦めてしまいそうな)方
Androidのシステムテスト(UI部分)の自動化
に踏み出してみたい方
受講条件
Androidアプリケーション開発の入門知識、および、
Javaプログラミングの経験を有していること
JUnitの利用経験があること

本研修の講義目的と到達目標(1/3)
4Copyright © 2016, NTT Software Corporation.
Androidアプリ開発プロジェクトで
• 実際の開発で無理なくユニットテストコードが書ける
• システム(UI)テスト自動化ツールについて
• 「どんな場面でどのツールを使えば良いか」分かる
• 簡単なテストシナリオを自動化できる

学習すること
自動ユニットテストの位置付けとメリット
Androidアプリのユニットテストの書き方
Android Studio、Robolectric、Mockitoを利用します
ありがちなシーン別に演習中心に学習します
システムテスト自動化ツールの特徴と
基本的なテストスクリプトの書き方
【座学+演習】Robotium、Espresso、UI Automator
【座学のみ】Appium

本研修で取り上げないこと
Android標準のユニットテスト
システムテスト自動化ツールの詳しい使い方

この研修のカバー範囲
ユニットテスト
自動化スキル
システムテスト
自動化スキル
色々なツールを広く薄く
実アプリに対するテストコードが
書けるレベルまで深く修得

本研修の講義内容
8
1日目 2日目
午前
9:30〜
12:00
 Androidテスティング基礎
 自動テストについての考え方
 テストアーキテクチャ
(演習あり)
 ユニットテストの自動化
 基本的な使い方
 ビジネスロジックのテスト
(演習あり)
昼休憩 12:00〜13:00
午後
13:00〜
17:30
 システムテストの自動化
 Robotium (演習あり)
 Espresso (演習あり)
 UI Automator (演習あり)
 Appium
 イベントリスナのテスト
(演習のみ)
 HTTP通信を行うメソッド
のテスト (演習のみ)
 DBアクセスするメソッドの
テスト (演習のみ)
 CI
※60〜90分ごとに適宜休憩を入れます
Copyright © 2016, NTT Software Corporation.

本研修で紹介するツール
9
ツール名概要
JUnit4 単体テストフレームワーク
Robotium 直感的に書けるのが特徴のUIテストフレームワーク
Espresso White-boxテストができるUIテストフレームワーク
UI Automator アプリにまたがったテストができる
UIテストフレームワーク
Appium Seleniumと似たAPIを持つUIテストフレームワーク
Robolectric 通常のJVM上でAndroidの単体試験を
実施するためのフレームワーク
Mockito モッククラスを簡単に作成するためのライブラリ
Android Studio Android向けの新しい統合開発環境
Gradle Android標準となったGroovyベースのビルドツール

1. Androidテスティング基礎
 自動テストについての考え方
 Androidの開発環境
 Local Unit TestとInstrumented Test
 JUnit4とAndroid Testing Support Library
 テスト対象アプリの紹介

自動テストについての考え方

【考え方】テスト自動化のメリット(1/2)
1. 新版リリース時に、既存の回帰テストを自動実行できる
間違った修正をすればテストに失敗する(デグレ防止)
安心してソースコードの整理(リファクタリング)・改造ができる
2. テストをもっと頻繁に、たくさん実行できる
3. 手動では困難・不可能なテストができる
4. 人的リソースの有効活用
テスト担当者はより良いテストケース設計に注力できる
CI (Continuous Integration) ツールと連携すれば、
自動テストの定期的な実行ですら機械任せにできる。
(参考)Mark Fewster, Dorothy Graham著「システムテスト自動化標準ガイド」(翔泳社) 第1章

【考え方】テスト自動化のメリット(2/2)
5. テストの一貫性と再現性
同一のテストを異なるデバイス上で実行できる
6. テストの再利用
何度もテストを実行することで、
初期コスト(テスト設計、実装など)を分散できる
7. 市場に早く提供できる
8. 自信が持てる

【考え方】テスト自動化に共通する問題
1. 自動テストツールの採用で全て解決すると思ってしまう
2. ダメなテストの自動化してしまう
ダメなテストを自動化してもダメなまま
3. 自動テストは新しいバグを発見しない
自動テストスクリプトを書く段階で新規バグは見つかる!
4. 自動テストを全てパスしても、バグは存在する
5. 自動テストのメンテナンスコストが高くなる
テスト対象が仕様変更する度に、テストスクリプトの修正が必要
6. 自動テストツールにバグがある
7. 組織のサポートが得られない
「初回は導入コストが大きいため、ほとんど利益は得られない」
ことを上司に分かってもらう必要がある

【考え方】どうすれば良いのか(1/4)
自動化の目的は効率化
手作業を繰り返すよりもコスト(稼働)が減る
 「自動化」には自動化するためのコスト
がかかる
 学習コスト
 最初にテストコードを書くコスト
 改造時にメンテし続けていくコスト
自動化すべき箇所はどこ?

自動化すべき箇所
テストコードが簡単に(少ない稼働で)書けるところ
イニシャルコストが少なくて済む
何度も繰り返しテストするところ
繰り返すほどペイする
改造しても仕様があまり変わらないところ
テストコードの修正稼働が少なくて済む
まずはここからはじめよう

ツール選定の考え方
「やりたいことが簡単にできるかどうか」が重要
ありがちなアンチパターン
1つのツールで全部やろうとする
全てのテストを自動化しようと頑張る
おすすめ!
複数ツールを併用する。
そのツールが得意なところだけ活用する。
テストクラス単位でのツール選択OK
簡単に書けるところだけ自動化する

ユニットテスト vs システム(UI)テスト
(原則)ユニットテスト自動化から着手すべき
ソース変更の度に再テストできるので効果が高い
改造時に最低限の品質が担保できる
テストを書くことで、曖昧だった仕様が明確になる
(例)引数にnullを指定したらどうなるか?
事情によってはシステムテスト自動化からでもOK
どちらに稼働がかかっているか？
何度もやるはめになっているのはどちらか？
全部自動化しようと思わないこと!

【考え方】ユニットテスト自動化で大事なこと(1/2)
サクサク実行できること
開発者はコードを書きながらテストも書く
テストの実行に時間がかかると効率が落ちてしまう
モックライブラリが使えること
簡単にテストを書くにはモックライブラリは必須
意味のあるテストを自動化すること
コスト的に見合うか考える
GUIや非同期処理など、大変すぎる箇所はやらない
→後フェーズで手動でテストすれば良い
ミスが入りそうな複雑なロジックのテストを優先する
単純なsetter/getterのテストを沢山書く意義は薄い

【考え方】ユニットテスト自動化で大事なこと(2/2)
ユニットテスト自動化ツールは、
以下の組み合わせがおすすめ(詳細は第4章で)
Mockito: モックライブラリの定番
Robolectric: サクサク実行できる!

【考え方】システムテスト自動化で大事なこと
テストスクリプトが簡単に書けること
UIは移ろいやすい
UI変更により作り直してもダメージが少ない
UI変更に強いテストコード設計にすること
Page Objectパターンは必須!
(参考)「4時間で学ぶ、効率的な自動テストスクリプトのメンテナンス」
https://goo.gl/PTdOfB (テスト自動化研究会チュートリアル資料)
簡単に自動化できるテスト項目に絞ること
テストツールによって得手不得手がある
各テストツールの得意な部分をつまみ喰いする
例外: (自動化コスト以上に)手動でのテストが面倒な場合

【考え方】(参考)Android特有の試験観点(1/3)
Activityのライフサイクルイベントに関する試験
onPause()、onCreate()でのデータの永続化・復元
特にホームキーが押下された時の振る舞いは見落しがち！
画面の向きが変わった時の動作 (onConfigurationChanged())
ネットワーク通信やDB操作などの重い処理に関する試験
ANR (Application Not Responding) エラーが発生しないか
データベース・ファイルシステム操作に関する試験
UIの細かい振る舞いに関する試験
UIコンポーネントの押下時/非押下時、選択時/非選択時の色
キーによるフォーカス移動の順番
etc.
(参考)Diego Torres Milano著「Android Application Testing Guide」(Packt Publishing)

機種に依存する振る舞いに関する試験
ネットワーク接続の種類・状況の違い
画面密度、解像度、物理的なサイズの違い
各種センサー(加速度センサーなど)のサポート状況の違い
入力デバイス(キーボードなど)の違い
etc
(参考)Diego Torres Milano著「Android Application Testing Guide」(Packt Publishing)

公式ドキュメント: Core App Quality Guidelines
http://developer.android.com/distribute/googleplay/quality/core.html
4つの観点 (※)
Visual Design and User Interaction
Functionality
Performance and Stability
Google Play
Test Procedure
CR-0: 全部の画面やダイアログについて、実際に遷移させてみる
CR-1: 全部の画面について、
ホームキーを押してから再度アプリを起動してみる
CR-2: 全部の画面について、別アプリに切り替えてから、
元のアプリに戻してみる
etc.
※ 具体例は、書籍「Androidアプリテスト技法」p.197参照
http://www.amazon.co.jp/dp/4798037044

Androidの開発環境

Androidの新しい開発環境: Android Studio
概要
「Google I/O 2013」で発表された、
新しいAndroid向け統合開発環境
IntelliJ IDEA Community Editionから派生
インストール
http://developer.android.com/sdk/index.html
インストーラが立ち上がるので、指示通りに進める
「Android Studioセットアップガイド」が参考になる
https://keiji.github.io/the-androidstudio-book/
※Eclipse+ADTは2015年12月で公式サポートが打ち切られました

Android Studioの特徴
ビルド環境の一元化
GUIからもコマンドライン(Gradle)からも同一バイナリ
を生成できる
Mavenベースの依存関係解決システム
ビルド設定ファイルに1行書くだけでOSSが利用できる
ビルドバリアントサポート
機能の大部分は同じだが、一部だけ振る舞いの異なる
ような、複数のアプリケーションを開発できる

Android Studioの動作環境
RAM: 最低2GB、推奨8GB
HDD: 最低2GB、推奨4GB (Android SDK含む)
解像度: 最低1280×800
Java: JDK8最新版 (JAVA_HOME環境変数)
CPU: 以下の機能を搭載していること
Intel VT-x
Intel EM64T (Intel 64)
Execute Disable (XD) Bit

Android Studioの初期設定
プロキシ設定
[Configure]→[Settings]→[HTTP Proxy]
C:¥Users¥ユーザー名¥.gradle¥gradle.properties
文字コード設定
[Configure]→[Settings]→[Editor]→[File Encoding]
3箇所全て「UTF-8」にする

Android Studioでプロジェクト作成/インポート
30
新規プロジェクト作成
Eclipseのプロジェクトをインポート

ソースコードのディレクトリ構成
31
Projectの中に
Module(アプリ本体)がある
テストコード①
プロダクトコード
Moduleのビルド定義ファイル
Projectのビルド定義ファイル
テストコード②
Android Studioの
Projectビューで確認する

Android Studioで良く使うショートカット
行の補完: Ctrl+Shift+Enter
コンテンツアシスト: Ctrl+SPC
テストの実行: Ctrl+Shift+F10
コードフォーマット: Ctrl+Alt+L
選択行の移動: Alt+Shift+↑↓
選択行の複製: Ctrl+D
テストメソッドの生成など: Alt+Insert
インテンション(EclipseのCtrl+1): Alt+Enter
Find Action: Shift2回押し
※ [File]＞[Settings...]＞[Keymap]で好みのショートカットに
変更できます。

Local Unit TestとInstrumented Test

Androidが用意しているテストの仕組み(1/2)
Local Unit Test
 JVM上(開発マシン上)で動作
高速だが実環境ではない
Android Framework APIは原則呼び出せない
(Robolectricを使えば可能。2日目に説明します。)
local JVM (Java SE)
テストコード
JUnitなど Android Framework API (空実装)
※ 用語の定義は https://developer.android.com/training/testing/start/index.html
を参考にしています

Androidが用意しているテストの仕組み(2/2)
Instrumented Test
Android上で動作する
実環境で動作するが、遅い
Android Framework API
呼び出しOK
(出典) https://developer.android.com/studio/test/index.html#Instrumentation

テストコードの配置
36
(src/main)
Instrumented Test
(src/androidTest)
Local Unit Test
(src/test)

app/build.gradleについて
dependenciesブロックの書き方に注意
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'commons-io:commons-io:2.5'
androidTestCompile 'com.android.support.test:runner:0.5'
testCompile 'org.robolectric:robolectric:3.0'
}
プロダクトコードで使うもの
(compile)
Instrumented Testで使うもの
(androidTestCompile)
Local Unit Testで使うもの
(testCompile)

コマンドラインからの実行
Instrumented Testを実行する場合（端末を接続した状態で）
Local Unit Test を実行する場合
Android Studioからの実行
テストしたいメソッドやクラスを選択して右クリック→[Run]
(Ctrl+Shift+F10) ※Preferences→keymap→Run context configuration
テストの実行
38
gradlew connectedAndroidTest
gradlew test
テストコードが緑に
なっている

JUnit4とAndroid Testing Support Library

JUnit4 (1/3)
Javaで広く使われているテストフレームワーク
http://junit.org/
40
public class MyJUnit4Test {
@Before
public void setUp() { /* テスト開始前の処理 */ }
@Test
public void 何かのテストをする() { /* テスト本体 */ }
@After
public void tearDown() { /* テスト終了後の処理 */ }
}

JUnit4 (2/3)
テスト結果が期待通りかどうかは
assertThat(actual, expected)
を使う
41
// この2つをstatic importしておく
import static org.hamcrest.CoreMatchers.*;
import static org.junit.Assert.assertThat;
...
// 使用例
assertThat(x, is(3));
assertThat(x, is(not(4)));
assertThat(myList, hasItem("3"));
※ 参考: マイナビニュース
『速攻解説! JUnit 4.4 - 新アサーションメソッド「assertThat」の用途とは』
http://news.mynavi.jp/articles/2007/07/20/junit1/

JUnit4 (3/3)
(参考)JUnit3との違い
JUnit3 JUnit4
テストクラス TestCaseクラスを継承特に制限なし
テストメソッ
ド
「test」から始まる
メソッド
「@Test」が付いているメソッド
前処理「setUp()」を
オーバーライド
「@Before」が付いているメソッド
後処理「tearDown()」を
オーバーライド
「@After」が付いているメソッド
検証 assertEquals(expected,
actual)
assertThat(actual, expected)

ATSL (Android Testing Support Library)
Instrumented Testで事実上必須のライブラリ
'com.android.support.test:<ライブラリ名>:<バージョン>'
ライブラリ名概要
runner 【必須】JUnit4が使えるようになる
rules 【必須】JUnit4でActivityにアクセスできるようになる
espresso:* Espressoが使えるようになる
uiautomator:* UI Automatorが使えるようになる
SDK Managerで以下をダウンロードしておく必要がある
Extras＞Android Support Repository
Extras＞Android Support Library

テスト対象アプリの紹介

テスト対象アプリの特徴
足し算をするシンプルなアプリケーション
テキストボックスの入力値を足し算した結果を表示
ダイアログによる表示
同一画面の「結果:」欄への表示
数字以外の入力時はエラーダイアログを表示

テスト対象アプリの画面遷移(1/3)
「ダイアログ表示」ボタンを押下した場合
「ダイアログ表示」
ボタンを押下する
AdditionViewActivity

「この画面に表示」ボタンを押下した場合
「この画面に表示」
ボタンを押下する
計算結果が
表示される

エラー時に表示するダイアログ
値1・値2のいずれかが数字以外の場合に表示

テスト対象アプリの内部仕様
入力内容を確認するバリデータ:
AdditionViewActivity#isValid(String, String): boolean
引数の両方がintに変換可能な場合: true
いずれかがintに変換できない場合や、nullの場合: false

ViewのリソースID
R.id.value1
R.id.value2
R.id.result_value
R.id.page_buttonR.id.dialog_button

【演習1-1】
単純なInstrumented Test
 演習課題
 ATSLのための設定

演習課題
以下の作業を通じて、単純なInstrumented Test
を完成させてください
Android Studioで
演習用プロジェクト「system-test-exercise」を開く
ATSLを使うように、build.gradleを修正する
以下のテストケースを作成する
テスト対象:
AdditionViewActivity#isValid(String, String)
テスト内容:
引数に"5", "8"を指定して呼び出した場合にtrueが返ること
テストクラス名: SimpleInstrumentationTest
テストメソッド名: isValid_normal()

ATSLのための設定: build.gradle
app/build.gradle
android {
defaultConfig {
...
testInstrumentationRunner ¥
'android.support.test.runner.AndroidJUnitRunner'
}
}
dependencies {
androidTestCompile ¥
'com.android.support.test:runner:0.5'
androidTestCompile ¥
'com.android.support.test:rules:0.5'
}

ATSLのための設定: テストクラス
テストクラス(app/src/androidTest/java/配下)
@RunWith(AndroidJUnit4.class)
public class SimpleInstrumentationTest {
@Rule
public ActivityTestRule<AdditionViewActivity> activityTestRule
= new ActivityTestRule<>( AdditionViewActivity.class );
private AdditionViewActivity activity;
@Before
public void setUp() throws Exception {
activity = activityTestRule.getActivity();
}
@Test public void isValid_normal() { ... }
}
日本語名のテストメソッドだと
メソッド指定のテスト実行不可
テスト対象Activity

https://www.ntts.co.jp/products/soft_dojyo/index.html

Androidテスティング実践基礎編

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Androidテスティング実践基礎編

Similar to Androidテスティング実践基礎編 (20)

More from 株式会社 NTTテクノクロス

More from 株式会社 NTTテクノクロス (8)

Recently uploaded

Recently uploaded (8)