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 (テスト自動化研究会チュートリアル資料)

簡単に自動化できるテスト項目に絞ること

テストツールによって得手不得手がある

各テストツールの得意な部分をつまみ喰いする

例外: (自動化コスト以上に)手動でのテストが面倒な場合


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 Guidelineshttp://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.value2R.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

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

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

Technology

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