Androidテスティング実践3 ユニットテスト・CI編

Androidテスティング実践
③ユニットテスト・CI編

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

3. ユニットテスト自動化
 ユニットテストについて
 ツールの概要
 ユニットテスト自動化で大事なこと
 プロダクトコードのテスト容易性
 「レガシーコード」改善
121Copyright © 2016, NTT Software Corporation.

ユニットテストについて

ユニットテストとは(1/2)
位置付け
開発者が安心するためのテスト(Developer Test)
プロダクトがデグレしないようにするためのセーフティネット
品質向上には寄与するが、品質保証が第一目的ではない
書くタイミング
プロダクトコードを書きながらテストも書く
プロダクトコード完成後ではない
テスト対象
ビジネスロジック
開発者が実装していて不安なところ
画面(GUI)の試験は対象外とすることが多い

ユニットテストとは(2/2)
テストを成功状態にしたままリファクタリングする
テストを失敗から成功に変化させるようにテスト対象コードを書く
テストを失敗させるテストコードを追加する
テストを失敗から成功に変化させるようにテスト対象コードを書く
失敗するテストコードを書く
(参考)TDD (テスト駆動開発)について
http://www.atmarkit.co.jp/ait/articles/1403/05/news035.html

プロダクトコードの「テスト容易性」
テスト容易性＝テストが書き易いプロダクトコード
テストしたいロジックはActivityに書かない
(匿名)内部クラス禁止
リスナやAsyncTaskは普通のクラスにする。
必要なものはコンストラクタで受け取れば良い。
テスト用にフィールドを差し替えられるように
「パッケージプライベート」なsetterやコンストラクタを
必要に応じて用意。
テスト時にoverrideしたいメソッドをパッケージプライベートに。
「本来privateだがテストコードからはアクセスさせたいもの」は
「パッケージプライベート」で。
テストはプロダクトと同じパッケージに置く。

「レガシーコード」改善
レガシーコード＝テストが無いコード
テストが無く仕様変更時に手がつけられないコード
レガシーコード改善
自動ユニットテストでカバーしてから改造(変更)する
そのままだとテストが書けない場合
テストが書けるように、必要最低限の改造をする
デグレしないように、IDEのリファクタ機能を駆使する
(手動で変更しない)
フィールド/メソッド/クラス追加やアクセス修飾子変更はOK
参考書籍「レガシーコード改善ガイド」
http://www.amazon.co.jp/dp/4798116831

ツールの概要
 Robolectric
 Mockito

Robolectricの特徴
Android向けユニットテストフレームワーク
http://robolectric.org/
MIT License
Androidフレームワークの動作をJVMでエミュレーション
APIレベル16から21をエミュレート可能(3.0版現在)
実行速度が速い
Mockitoとの併用が可能
広い範囲のエミュレーションサポート
ビューの展開、リソース取得、データベース操作、etc.
とはいえ、JVM上のエミュレーションに過ぎないことに注意
128
ビジネスロジックの検証がメインとなる
ユニットテストでは十分使える
Copyright © 2016, NTT Software Corporation.
※http://robolectric.org/ よりロゴを引用

Robolectricのコンセプト
高速に実行できるLocal Unit Testの欠点
(Android Framework APIが使えない)
をRobolectricが克服
ユニットテスト・TDDで重要な
「開発のリズムを損わないサクサクさ」
でAndroid APIが絡んだ部分のテスト実行が可能になる
local JVM (Java SE)
テストコード
JUnitなど
Android Framework API
(空実装→Robolectric)
プロダクトコード

Robolectricの基本的な使い方(1/3)
基本はJUnit4
テストランナーを指定する(@RunWithアノテーション)
テストの前提条件を指定する(@Configアノテーション)
constantsの指定は必須(Robolectricがgradleの情報を得るため)
その他、エミュレートしたいAPIレベルの指定なども可能。
http://robolectric.org/configuring/
130
@RunWith(RobolectricGradleTestRunner.class)
@Config(constants = BuildConfig.class)

@RunWithと@Configをまとめて書くと
＠Configは設定ファイルに書いても良い(おすすめ!)
ファイル名:
src/test/resources/robolectric.properties
131
@Config(constants = BuildConfig.class)
public class MyFirstRobolectricTest { .... }
constants=[パッケージ名].BuildConfig

Shadowオブジェクト
AndroidフレームワークAPIの実装オブジェクト群
Androidフレームワークが提供するクラスと1:1対応
Shadowオブジェクトの使いみち
Androidフレームワークでは提供されていないAPIを提供
テストに有用な内部状態を知るためのAPIが中心
ImageView iv = (ImageView) activity.findViewById(.....);
ShadowImageView shadow = Shadows.shadowOf(iv);
ImageViewに対応するShadowオブジェクト
ShadowImageView shadow = Shadows.shadowOf(iv);
int resId = shadow.getImageResourceId();
本来なら不可能な
ImageViewの画像リソースIDにアクセス

Robolectricの制限事項(1/2)
Robolectric本体の制限事項
3.0版:API Level 21 (Android 5.0)までサポート
3.1版:API Level 23 (Android 6.0)までサポート
targetSdkVersion=23では動作させるためには、
以下のいずれかの対応が必要
※ https://github.com/robolectric/robolectric/issues/1932 参照
robolectric.propertiesに「sdk=22」と追記する
build.gradleのdependenciesに、以下を追記する。
testCompile 'org.khronos:opengl-api:gl1.1-android-2.1_r1'
※compileSdkVersionとappcompat-v7のバージョンは
同じでなければならない点に注意！

Robolectricの制限事項(2/2)
プロジェクトのbuild.gradleファイル
// (省略)
android {
// (省略)
compileSdkVersion 21
// (省略)
defaultConfig {
// (省略)
targetSdkVersion 21
// (省略)
}
// (省略)
}
dependencies {
compile 'com.android.support:appcompat-v7:21.
// (省略)
}
新規PJ作成時は最新verになっているの
でcompileSdkVersionに合わせて修正

Mockitoの紹介
特徴
クラス定義から、そのクラスのスタブを生成できる
実オブジェクトの一部メソッドの動作を変更できる
MIT License
URL
https://github.com/mockito/mockito (公式ホームページ)
http://goo.gl/pOFyaQ (公式ドキュメント)
http://tech.cm55.com/wiki/mockito/Manual (日本語紹介記事)
※https://github.com/mockito/mockito よりロゴを引用

mockの概念
Hoge mockHoge = mock(Hoge.class);
Hoge hoge = new Hoge();
例えば
で生成したmockHogeは
と違い
メソッドの戻り値を事前に定義したり
メソッドが呼ばれた事を後から確認したり
できる

spyの概念
Hoge spyHoge = spy(new Hoge());
Hoge hoge = new Hoge();
例えば
で生成したspyHogeは
と同じ実装を持ちつつ
一部のメソッドの戻り値を事前に定義したり
メソッドが呼ばれた事を後から確認したり
できる

Mockitoの使い方
基本
モックの作成(mock)
メソッドの振る舞い変更(when, thenReturn, thenThrow)
メソッドが呼び出されたことを確認(verify)
実オブジェクトの振る舞い変更
spyオブジェクト生成(spy)
メソッドの振る舞い変更(doReturn, doNothing, doThrow)
公式ドキュメントのコード例参照
(1) Let's verify some behaviour!
(2) How about some stubbing?
(12) doReturn()|doThrow()| doAnswer()|doNothing()|
doCallRealMethod() family of methods
(13)Spying on real objects

【演習3-1】ユニットテスト環境構築
 演習課題
 ユニットテスト対応
 Robolectricのテストサンプル作成
 テスト実行

演習課題
以下作業を通じて、テスト環境構築の方法を習得
してください。
Android Studio上でアプリを新規作成する
ビルドスクリプトを修正してRobolectric + Mockito
対応にする
Robolectricのテストサンプルを追加し、実行してみる

ユニットテスト対応(Gradle)
141
// (省略)
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
// (省略)
testCompile 'junit:junit:4.12'
testCompile 'org.hamcrest:hamcrest-library:1.3'
testCompile 'org.robolectric:robolectric:3.0'
testCompile 'org.mockito:mockito-core:1.10.19'
// (省略)
} (挿入)必要なライブラリの宣言
詳細は別途提示
Moduleのbuild.gradleファイル

Robolectricのテストサンプル作成(1/2)
以下のクラスを作成
(テスト対象クラス:EditActivity.javaのクラス名の上で
Alt+Enter→Create Test)
public class MyFirstRobolectricTest {
private EditActivity activity;
@Before
public void setup() {
activity = Robolectric.buildActivity(EditActivity.class).create().get();
}
@Test
public void testSomething() throws Exception {
assertTrue(activity != null);
}
}

Robolectricのテストサンプル作成(2/2)
 robolectric.propertiesファイル作成
constants=[パッケージ名].BuildConfig

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

(参考)Mavenのプロキシ設定
プロキシ配下で利用する場合は以下の設定も必要
以下のディレクトリにsettings.xmlを配置する
Windows系: c:¥Users¥ユーザー名¥.m2¥
settings.xmlの内容は以下の通り
<?xml version="1.0" encoding="UTF-8"?>
<settings>
<proxies>
<proxy>
<active>true</active>
<protocol>http</protocol>
<host>【プロキシのホスト名】</host>
<port>【プロキシのポート番号】</port>
</proxy>
</proxies>
</settings>

AndroidのHTTP通信ライブラリOkHttpのサブコンポー
ネントとして配布
https://github.com/square/okhttp/tree/master/mockwebserver
Apache License Version 2.0
セットアップ方法
build.gradleのdependenciesブロックに以下を記述
サーバの開始方法
testCompile 'com.squareup.okhttp:mockwebserver:2.7.5'
MockResponse response = ... (返して欲しいレスポンスを組み立てる)
MockWebServer server = new MockWebServer();
server.enqueue(response);
server.start();
URL mockServerUrl = server.url("/test").url();
URLのprefix(任意)を指定
(参考)MockWebServerについて(1/2)

(参考)MockWebServerについて(2/2)
MockResponse(返して欲しいレスポンス)組み立て方法
MockWebServer終了の方法(tearDown()で呼び出す)
プロキシ設定の無効化(MockServer開始前に呼び出す)
環境により不要な場合もあり。環境への依存を下げるため書いておくのがベター。
MockResponse response = new MockResponse()
// JSONのContent-Type指定
.addHeader("Content-Type",
"application/json; charset=utf-8")
.setResponseCode(HTTPレスポンスコード)
.setBody(HTTPレスポンスボディ);
server.shutdown();
System.clearProperty("proxyHost");
System.clearProperty("proxyPort");

テスト対象アプリの解説

【演習3-2,3】ビジネスロジックのテスト

【演習3-4】イベントリスナのテスト

【演習3-5】
HTTP通信を伴うメソッドのテスト

【演習3-6】
データベースアクセスのテスト

4. CIの実現
 CIの概要
 Android開発プロジェクトに適用する
 (参考)Instrumented Testも実行する場合

CIとは
継続的インテグレーション(Continuous Integration)
自動的に以下を実施してくれる
リポジトリから最新のソースコード一式を取得
ビルドや自動テストなど実行し、その結果を通知
通常は専用の
サーバで動かす

CIのメリット
ビルド・テストに失敗するコードがコミットされたとき
に、いち早く検知し、対策を打つことができる。
Androidのように、ビルドや全テスト実行に時間がかか
る場合でも、CIサーバに全てお任せすれば、生産性向上
につながる。

Jenkins
概要
広く使われているCIサーバ
https://jenkins.io/
MIT License
特徴
インストールが簡単
コマンドライン1行でOK (java -jar jenkins.war)
yumやapt-getでインストールすることも可能
設定が簡単
全てWeb画面から設定できる
※https://github.com/jenkinsci/jenkins よりロゴを引用

Android開発プロジェクトに適用する
前提条件
Android StudioとGradleでプロジェクトが構築されていること
ソースコードがSubversionやGitで管理されており、
CIサーバからチェックアウトできること
この研修で実現できる項目
ビルド結果
Android Lint結果
Local Unit Test結果
この研修では概要のみ触れる項目
Instrumented Test結果
(エミュレータの起動が不安定、実行時間が非常に長くなるなどの
問題があるため、導入には試行錯誤が必要)

プラグインのインストール
[Jenkinsの管理]→[プラグインの管理]
(★)Android Lint Plugin
Gradle plugin
Subversion plugin
(ソースコードリポジトリがSubversionの場合)
Git plugin
(ソースコードリポジトリがGitの場合)
JUnit plugin
※ Jenkins 2.0からは、セットアップ時に「Suggested Plugins」を選択
していれば、★印のプラグインのみインストールすればOK

[Jenkinsの管理]→[システムの設定]
[Jenkinsの管理]→[Global Tool Configuration]
原則デフォルト設定のままでOK
既にインストールされているJDKやgitなどを
利用したい場合はそのパスを指定しても良い。

新規ジョブ作成
「フリースタイル・プロジェクトのビルド」を選択
ソースコード管理
SubversionかGitを選択し、リポジトリのURLなどを入力
ビルド・トリガ
お好みで。迷ったら「SCMをポーリング」で良い
ビルド
[ビルド手順の追加]→[Invoke Gradle script]
[Use Gradle Wrapper]を選択
Tasksに[clean lint testDebugUnitTest]と入力
ビルド後の処理
[ビルド後の処理の追加]→[Publish Android Lint results]
([Lint files]は空欄でOK)
[ビルド後の処理の追加]→[JUnitテスト結果の集計]
[テスト結果XML]に[app/build/test-results/debug/*.xml]と入力

(参考)Instrumented Testも実行する場合
[Jenkinsの管理]→[プラグインの管理]
Android Emulator Pluginをインストールする
ジョブの設定
[ビルド環境]→[Run an Android emulator during build]にチェック
起動したいエミュレータの情報を入力
[Common emulator options]→[Show emulator window]はチェックし
ない
[Invoke Gradle script]→[Tasks]
[connectedAndroidTest]を追加
[ビルド後の処理]→[JUnitテスト結果の集計]
[テスト結果XML]を[app/build/**/TEST*.xml]に修正

まとめ

この研修で説明したこと
自動テストについての考え方
Androidのテストツール基礎知識
Local Unit Test, Instrumented Test, ATSL, ...
システムテスト自動化ツールの使い方
Robotium, Espresso, UI Automator, Appium
ユニットテスト自動化ツールの使い方
各種テストは以下のテクニックを駆使して実現する
Android Studioのリファクタリング機能
テスト用のメソッド・コンストラクタの追加
Mockitoのmock()とspy()
MockWebServer
CIの実現方法

最後に
プロダクトコードを自動化したユニットテストで
カバーすることで、ソース修正時の安心感が劇的に上がります。
既にレガシーコードがある場合は、全部やろうとせず、
CIやユニットテストから少しずつ始めて行くと良いでしょう。
テストが全く無くても、CIだけ始めてみる。
 Android Studioに移行するだけで始められます。
新しく機能追加したところだけでもテストを書いてみる。
リリースを何度も行うプロジェクトでは、
システムテスト自動化にもチャレンジしてみてください。

おわり
お疲れ様でした

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

Androidテスティング実践3 ユニットテスト・CI編

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Androidテスティング実践3 ユニットテスト・CI編

Similar to Androidテスティング実践3 ユニットテスト・CI編 (20)

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

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

Recently uploaded

Recently uploaded (16)

Androidテスティング実践3 ユニットテスト・CI編