Slide 1

Slide 1 text

変更に強いEspressoテストコード を効率良く書こう 2017.03.09 外⼭ 純⽣ (sumio_tym) 1 DroidKaigi 2017

Slide 2

Slide 2 text

⾃⼰紹介 p ⽒名: 外⼭ 純⽣ (TOYAMA Sumio) @sumio_tym (Twitter) / @sumio (GitHub) p 所属: NTTソフトウェア株式会社 p 業務内容: p 社内Androidプロジェクトの技術⽀援 p 社内Androidプロジェクトのテスト⾃動化⽀援 p プライベート: p STAR(テスト⾃動化研究会) p @IT連載「スマホ向け無料システムテスト⾃動化 ツール」(UI Automator / Appiumの回を担当) 2

Slide 3

Slide 3 text

お話しすること AndroidのUIテストツールEspresso について、以下を紹介します 3 プロダクトの仕様変更に強いテストを Espresso Test Recorderを使って 効率的に書いていく⽅法

Slide 4

Slide 4 text

話の流れ 1.イントロダクション p 効率的にテストを書くこと p 変更に強いテストを書くこと 2.Espressoの基本 3.Espresso Test Recorderとその限界 4.実践!変更に強いテストを効率的に書く p サンプルアプリについて p テスト⾃動化対象の選定 p 操作・検証の記録 p 修正 4

Slide 5

Slide 5 text

1.イントロダクション p 効率的にテストを書くこと p 変更に強いテストを書くこと 2.Espressoの基本 3.Espresso Test Recorderとその限界 4.実践!変更に強いテストを効率的に書く p サンプルアプリについて p テスト⾃動化対象の選定 p 操作・検証の記録 p 修正 5

Slide 6

Slide 6 text

効率的にテストを書くことの⼤切さ テスト⾃動化の⽬的は⾊々ある pテスト実施⼯数を削減したい p⼿順ミス、確認ミスをなくしたい p回帰試験を⾃動化して安⼼したい petc. 6

Slide 7

Slide 7 text

効率的にテストを書くことの⼤切さ pどんなケースでも テストを書くのに時間を浪費する と⽬的達成が難しくなる p特に、着⼿するときは、 効率的に(楽して)テストを書く ことはとても⼤切 7

Slide 8

Slide 8 text

UIテスト実装時のボトルネック(イメージ) 操作対象の特定が⼤変 (例)ダイアログのメッセージ⽂字列を検証する p ダイアログタイトル: 「結果」 p ダイアログメッセージ: 「6 + 7 = 13」 8

Slide 9

Slide 9 text

9 条件: ⼦孫に「結果」というtextを持つView の兄弟が⾃分の祖先におり、 かつ、⾃分はTextViewである。 UIテスト実装時のボトルネック(イメージ)

Slide 10

Slide 10 text

10 䗤䗣䗋䗞䗚䗬 䗖䗡䗡䗄䗛 䗬䗞䗩䗝䖸䗡䗖䗨䗨䗃䗖䗢䗚 䗞䗨 5FYU7JFXDMBTTHFU/BNF 䗞䗨䖹䗚䗨䗘䗚䗣䗙䗖䗣䗩䗄䗛䖶 䗝䗖䗨䗈䗞䗗䗡䗞䗣䗜 䗝䗖䗨䖹䗚䗨䗘䗚䗣䗙䗖䗣䗩 䗬䗞䗩䗝䗉䗚䗭䗩 ✿᧠ DIFDL 䗢䗖䗩䗘䗝䗚䗨 䗬䗞䗩䗝䗉䗚䗭䗩 ↓を⾃分でひねり出すのは正直厳しい... UIテスト実装時のボトルネック(イメージ)

Slide 11

Slide 11 text

ボトルネック解消の切り札 Espresso Test Recorder pAndroid Studio 2.2より搭載 p以下をEspressoテストコードとして出⼒ pUIの操作 p結果の検証(assertion) とはいえ、うまく動かないケースも... 11

Slide 12

Slide 12 text

効率的にテストを書くためには? できるだけ Espresso Test Recorderが得意な テストケースを⾃動化対象にする pもちろん ⾃動化の⽬的から外れていないか の検討は必要です。 12

Slide 13

Slide 13 text

効率的にテストを書くためには? そのため知っておくと良いことは? pEspresso Test Recorderが 得意なケース/不得意なケース pEspressoのコードを⼿で書けば 簡単なケース/困難・不可能なケース 後程紹介します! 13

Slide 14

Slide 14 text

1.イントロダクション p 効率的にテストを書くこと p 変更に強いテストを書くこと 2.Espressoの基本 3.Espresso Test Recorderとその限界 4.実践!変更に強いテストを効率的に書く p サンプルアプリについて p テスト⾃動化対象の選定 p 操作・検証の記録 p 修正 14

Slide 15

Slide 15 text

変更に強いテストとは? 画⾯の仕様変更が発⽣したときに テストコード修正インパクトが⼩さい こと 15

Slide 16

Slide 16 text

変更に弱いテストの典型例 p操作対象を特定するコードが、 多くのテストケースにコピー されている場合 16

Slide 17

Slide 17 text

変更に弱いテストの典型例(イメージ) 17 ログイン画⾯のテストケースを考える 1. ID/PWを⼊れて「ログイン」と表⽰されたボタン を押すと〜されること 2. PWが未⼊⼒で「ログイン」と表⽰されたボタン を押すと〜されること 3. IDが未⼊⼒で「ログイン」と表⽰されたボタン を押すと〜されること 後で「ログイン」ボタンが「OK」ボタンに 仕様変更されると、全部修正が必要!

Slide 18

Slide 18 text

変更に弱いテストの典型例(イメージ) 18 ログイン画⾯のテストケースを考える 1. ID/PWを⼊れて「ログイン」と表⽰されたボタン を押すと〜されること 2. PWが未⼊⼒で「ログイン」と表⽰されたボタン を押すと〜されること 3. IDが未⼊⼒で「ログイン」と表⽰されたボタン を押すと〜されること Espresso Test Recorderで普通に記録すると、 こうなってしまう!

Slide 19

Slide 19 text

変更に強くするには?(イメージ) 同じ操作を共通部分として抽出する 1. ID/PWを⼊れてログインすると〜されること 2. PWが未⼊⼒でログインすると〜されること 3. IDが未⼊⼒でログインすると〜されること ※ここで、「ログインする」= 「『ログイン』と表⽰されたボタンを押す」 後で「ログイン」ボタンが「OK」ボタンに 仕様変更されても「※」だけ修正すればOK cf. PageObject デザインパターン 19

Slide 20

Slide 20 text

変更に強くするには?(イメージ) 同じ操作を共通部分として抽出する 1. ID/PWを⼊れてログインすると〜されること 2. PWが未⼊⼒でログインすると〜されること 3. IDが未⼊⼒でログインすると〜されること ※ここで、「ログインする」= 「『ログイン』と表⽰されたボタンを押す」 Espresso Test Recorderで記録した場合、 共通部分の抽出は⼿作業で⾏う必要がある! 20

Slide 21

Slide 21 text

変更に強いコードに直す⽅法は? 以下を修得しておくと負担が減る pEspresso Test Recroderの出⼒に対して 具体的な修正⽅針をイメージする p修正作業で良く使うAndroid Studioの リファクタ機能を覚える (キーボードショートカットも覚える) 後程紹介します! 21

Slide 22

Slide 22 text

ここまでのまとめ 効率的にテストを書くためには pEspresso Test Recorderの得意箇所から着⼿ p 得⼿不得⼿を知っておく必要がある 変更に強いテストにするには pEspresso Test Recorderの出⼒コードから、 ⼿作業で共通部分を抽出 p リファクタ機能を駆使した具体的な修正⽅法を 修得しておく必要がある 22

Slide 23

Slide 23 text

1.イントロダクション p 効率的にテストを書くこと p 変更に強いテストを書くこと 2.Espressoの基本 3.Espresso Test Recorderとその限界 4.実践!変更に強いテストを効率的に書く p サンプルアプリについて p テスト⾃動化対象の選定 p 操作・検証の記録 p 修正 23

Slide 24

Slide 24 text

Espressoの概要 p Android公式のUIテストフレームワーク p コードの簡潔さ・信頼性の⾼さに定評あり p テスト実⾏速度が⽐較的速い p WebViewにも対応 p URL phttps://goo.gl/x8eP5C phttps://goo.gl/lmrlJI 24 (※) https://google.github.io/android-testing-support-library/docs/espresso/cheatsheet/ よりロゴを引⽤ (※)

Slide 25

Slide 25 text

Espressoのセットアップ ビルド環境設定(https://goo.gl/WlXSCq) p Android Support Repositoryのインストール p build.gradleのdependenciesブロック (以下の2つのモジュールを宣⾔) p configuration: androidTestCompile p group: com.android.support.test.espresso p module: 1. espresso-core (Recorderが⾃動設定する) 2. espresso-contrib (⼿動で追加する) 25

Slide 26

Slide 26 text

Espressoのセットアップ 26 androidTestCompile( 'com.android.support.test.espresso:espresso-core:2.2.2', { exclude group: 'com.android.support', module: 'support-annotations' } ) プロダクトコードとコンフリクト するモジュールを除外する。 (ビルドエラー時のメッセージを参照)

Slide 27

Slide 27 text

Espressoのセットアップ 27 androidTestCompile( 'com.android.support.test.espresso:espresso-contrib:2.2.2', { exclude group: 'com.android.support', module: 'support-annotations' exclude group: 'com.android.support', module: 'support-v4' exclude group: 'com.android.support', module: 'appcompat-v7' exclude group: 'com.android.support', module: 'design' exclude group: 'com.android.support', module: 'recyclerview-v7' } )

Slide 28

Slide 28 text

Espressoのセットアップ テスト⾛⾏端末のアニメーション設定 (「開発者オプション」の以下をOFFにする) p ウィンドウアニメスケール p トランジションアニメスケール p アニメーター再⽣時間スケール 28

Slide 29

Slide 29 text

Espressoのテストコード p src/androidTest/java に配置 p Android Testing Support Libraryに従う ※ Espresso Test Recorderが雛型を⾃動⽣成 29 @RunWith(AndroidJUnit4.class) public class MyEspressoTest { @Rule public ActivityTestRule<...> activityTestRule = ...; ... }

Slide 30

Slide 30 text

Espresso APIの概要 p 以下の基本形を理解する ※perform()・check()は省略可能 30 onView(ViewMatcher) .perform(ViewAction) .check(ViewAssertion); n「ViewMatcher」にあてはまるViewに対して n「ViewAction」を実⾏した結果 nそのViewが「ViewAssertion」 を満たすことを確認する

Slide 31

Slide 31 text

Espresso APIの概要 31 onView(ViewMatcher) .perform(ViewAction) .check(ViewAssertion); ⽤意されているAPIの⼀覧は チートシート(https://goo.gl/sH9eax)参照 n「ViewMatcher」にあてはまるViewに対して n「ViewAction」を実⾏した結果 nそのViewが「ViewAssertion」 を満たすことを確認する

Slide 32

Slide 32 text

Espressoで操作・確認できること p Button、EditText、TextView、ダイアログな どの基本的なコンポーネント p ListView - onData() p RecyclerView – RecyclerViewActions ※ViewHolder内のViewの確認には⼯夫が必要 p NavigationDrawer・NavigationView - DrawerActions・NavigationViewActions p DatePicker・TimePicker - PickerActions p WebView内HTML - onWebView() https://goo.gl/OMfVyZ 参照 32

Slide 33

Slide 33 text

Espressoで不得意・困難なこと Viewのプロパティの動的な取得 (事前に分かっている値との⼀致確認はできる) p View AとView Bに同じテキスト (事前に分からない) が表⽰されていることを確認する、など 操作・確認対象が明確でないケース p 複雑なジェスチャー(画⾯を指でなぞる など) p 画像の⽐較(ImageViewなど) 33

Slide 34

Slide 34 text

Espressoで不得意・困難なこと AsyncTask以外の⾮同期待ち合わせ p IdlingResourceを実装すれば可能 p 別Activityに遷移すると 「UIが変化するまで待つ」のが難しい 34

Slide 35

Slide 35 text

ここまでのまとめ 環境設定は、 Espresso Test Recorderに任せるのが楽 p 端末のアニメーションOFFなど⼿動設定も必要 ⼤部分のUI部品の操作・確認をサポート p 公式にチートシートあり 以下については近付かないのが無難 p Viewプロパティの動的な取得 p 操作・確認対象が明確でないケース p 別画⾯遷移後の⾮同期待ち合わせ 35

Slide 36

Slide 36 text

1.イントロダクション p 効率的にテストを書くこと p 変更に強いテストを書くこと 2.Espressoの基本 3.Espresso Test Recorderとその限界 4.実践!変更に強いテストを効率的に書く p サンプルアプリについて p テスト⾃動化対象の選定 p 操作・検証の記録 p 修正 36

Slide 37

Slide 37 text

動作に必要なもの pテスト対象アプリのソースコード pAndroid Studio 2.2以上 pエミュレータ/実機 (テスト記録時に使⽤) 37

Slide 38

Slide 38 text

動かしかた 1. エミュレータ/実機をadb接続しておく 2. テスト対象アプリのプロジェクトを Android Studioで開く 3. メニュー Run> Record Espresso Test 38

Slide 39

Slide 39 text

操作の記録 p 起動したテスト対象アプリを直接操作する p 操作した内容は「Record Your Test」ダイ アログに反映されていく (応答が遅いので、1アクションの都度、反 映されるまで待つのがお奨め) 39 ※以降、 https://github.com/googlecodelabs/android-testing で公開されているサンプルアプリを使ったスクリーンショットを掲載しています。

Slide 40

Slide 40 text

アサーションの記録 p 「Record Your Test」 >「Add Assertion」 40

Slide 41

Slide 41 text

アサーションの記録 41 p 画⾯キャプチャが表⽰され、 アサーションを記録するモードに移⾏

Slide 42

Slide 42 text

アサーションの記録 42 p 画⾯キャプチャ上で、検証したい箇所を選択 p 検証内容を選択し「Save Assertion」

Slide 43

Slide 43 text

記録の終了 43 p 「Record Your Test」 >「OK」 p テストクラス名を⼊⼒ ※ build.gradleが未設定だと、 このタイミングで⾃動設定 するかどうか確認される。

Slide 44

Slide 44 text

限界 - 注意点 p 操作がもっさり (できれば実機で記録するのが良い) p ⾮対応のコンポーネントがある p 確認⼿段が限定されている 「テキスト⼀致・表⽰されているかどうか」のみ p 操作誤りをアンドゥできない p 必ず最初のActivity起動から記録される p ランドスケープ⾮対応(Assertion) 44

Slide 45

Slide 45 text

限界 - コンポーネント別対応状況 45 コンポーネント 対応状況 TextView ○ EditText ○ Button ○ NavigationDrawer ○ (専⽤APIは使われない) RecyclerView △ (専⽤APIは使われない) ListView △ (onData()が使われない) Picker系 △ (spinner系のみ可) WebView内HTML ×

Slide 46

Slide 46 text

限界 - バグと思われるもの p ⾃動⽣成されるchildAtPosition()が、 正しく位置をカウントしない (Issue 231461) MoreViewMatchersクラス(⾃作)修正版あり p AsyncTask以外のバックグラウンドスレッド (OkHttpやRxJavaなど)を使っていると、 巨⼤なsleepコードが挿⼊されることがある 例: Thread.sleep(3596585)←約1時間! 46

Slide 47

Slide 47 text

ここまでのまとめ p Espresso Test Recorderの操作は 直感的で分かりやすい p ただし、何でも記録できるわけでは無い ので、事前に限界を知っておくと良い pRecyclerView、ListView、Picker系、 WebViewがある画⾯は注意が必要 (必要に応じてソースを書き換える) 47

Slide 48

Slide 48 text

1.イントロダクション p 効率的にテストを書くこと p 変更に強いテストを書くこと 2.Espressoの基本 3.Espresso Test Recorderとその限界 4.実践!変更に強いテストを効率的に書く p サンプルアプリについて p テスト⾃動化対象の選定 p 操作・検証の記録 p 修正 48

Slide 49

Slide 49 text

サンプルアプリ 49 (Chrome Custom Tabs) タイトル2 タイトル1 ・・・・ タイトル3 タイトル2 Qiita記事⼀覧 お気に⼊り⼀覧 ★(CheckBox)タップで お気に⼊り⼀覧に⼊る タイトルタップで 詳細画⾯へ 記事詳細 NavigationDrawerで切り替え

Slide 50

Slide 50 text

1.イントロダクション p 効率的にテストを書くこと p 変更に強いテストを書くこと 2.Espressoの基本 3.Espresso Test Recorderとその限界 4.実践!変更に強いテストを効率的に書く p サンプルアプリについて p テスト⾃動化対象の選定 p 操作・検証の記録 p 修正 50

Slide 51

Slide 51 text

効率的にテストを書くためには? pできるだけ Espresso Test Recorderが得意な テストケースを⾃動化対象にする pもちろん ⾃動化の⽬的から外れていないか の検討は必要です。 51 再掲

Slide 52

Slide 52 text

テスト⾃動化対象の選択⽅針 以下の条件に合う画⾯のテストを 優先的に⾃動化する (Espressoは画⾯単位で試験する) pEspresso Test Recorderが対応してい るコンポーネントが多い p(対応していないコンポーネントは) ⼿書きでEspresso APIを呼び出せば 簡単に書ける 52

Slide 53

Slide 53 text

コンポーネント別対応状況まとめ 53 コンポーネント Recorder ⼿書き TextView ○ ○ EditText ○ ○ Button ○ ○ NavigationDrawer ○ ○ RecyclerView △ △ ListView △ ○ Picker系 △ ○ WebView内HTML × ○ より多く より 少なく

Slide 54

Slide 54 text

その他対応状況まとめ 54 やりたいこと Recorder ⼿書き 表⽰テキスト⼀致確認 ○ ○ Viewの表⽰⾮表⽰確認 ○ ○ その他の確認 × △ (画像⼀致確認) × × Viewプロパティ の動的な取得 × × 複雑なジェスチャー × × AsyncTask以外の⾮同 期待ち合わせ × △ より多く より 少なく 対象外

Slide 55

Slide 55 text

サンプルアプリで考える 55 (Chrome Custom Tabs) タイトル2 タイトル1 ・・・・ タイトル3 タイトル2 Qiita記事⼀覧 お気に⼊り⼀覧 ★(CheckBox)タップで お気に⼊り⼀覧に⼊る タイトルタップで 詳細画⾯へ 記事詳細 NavigationDrawerで切り替え 別プロセス

Slide 56

Slide 56 text

56 タイトル2 タイトル1 ・・・・ タイトル3 タイトル2 Qiita記事⼀覧 お気に⼊り⼀覧 ★(CheckBox)タップで お気に⼊り⼀覧に⼊る • 画像の変化は確認不可 Ø CheckBoxなので 「チェック状態かどうか(isChecked())」 で判定する。 サンプルアプリで考える(★のタップ操作)

Slide 57

Slide 57 text

57 タイトル2 タイトル1 ・・・・ タイトル3 タイトル2 Qiita記事⼀覧 お気に⼊り⼀覧 ★(CheckBox)タップで お気に⼊り⼀覧に⼊る • RecyclerViewのビューアイテム内の操作・ 確認が難しい Ø 汎⽤メソッドを⽤意して対応する (後述) サンプルアプリで考える(★のタップ操作)

Slide 58

Slide 58 text

58 タイトル2 タイトル1 ・・・・ タイトル3 タイトル2 Qiita記事⼀覧 お気に⼊り⼀覧 ★タップで お気に⼊り⼀覧に⼊る • お気に⼊りに⼊れたものと同じタイトル (事前に決まらない)が有ることの確認は不可 Ø サーバーレスポンスを固定する (事前に決まるようにする) Ø お気に⼊りの数が0→1になったこと への確認にとどめる(今回はこちらを採⽤) サンプルアプリで考える(お気に⼊り⼀覧)

Slide 59

Slide 59 text

今回⾃動化するテストケース 1. ☆をタップすると★に切り替わること 2. ★をタップすると☆に切り替わること 3. お気に⼊りが0件の状態で、☆をタップし て★にすると、お気に⼊り画⾯の表⽰件数 が1件になること (1件⽬が存在し、2件⽬が存在しないこと) 59

Slide 60

Slide 60 text

1.イントロダクション p 効率的にテストを書くこと p 変更に強いテストを書くこと 2.Espressoの基本 3.Espresso Test Recorderとその限界 4.実践!変更に強いテストを効率的に書く p サンプルアプリについて p テスト⾃動化対象の選定 p 操作・検証の記録 p 修正 60

Slide 61

Slide 61 text

変更に弱いテストの典型例(イメージ) 61 ログイン画⾯のテストケースを考える 1. ID/PWを⼊れて「ログイン」と表⽰されたボタン を押すと〜されること 2. PWが未⼊⼒で「ログイン」と表⽰されたボタン を押すと〜されること 3. IDが未⼊⼒で「ログイン」と表⽰されたボタン を押すと〜されること Espresso Test Recorderで普通に記録すると、 こうなってしまう! 再掲

Slide 62

Slide 62 text

変更に強くするには?(イメージ) 同じ操作を共通部分として抽出する 1. ID/PWを⼊れてログインすると〜されること 2. PWが未⼊⼒でログインすると〜されること 3. IDが未⼊⼒でログインすると〜されること ※ここで、「ログインする」= 「『ログイン』と表⽰されたボタンを押す」 後で「ログイン」ボタンが「OK」ボタンに 仕様変更されても「※」だけ修正すればOK cf. PageObject デザインパターン 62 再掲

Slide 63

Slide 63 text

Recorderで記録するもの テスト時に操作・確認する可能性 のあるものを⼀度だけ記録する p ログインの例では・・・ p IDを⼊⼒する p PWを⼊⼒する p ログインボタンを押す p ログインエラーメッセージを確認する 63

Slide 64

Slide 64 text

サンプルアプリに当てはめると p NavigationDrawerを開いて 投稿⼀覧画⾯に切り替える p 投稿⼀覧画⾯で☆をタップする p 投稿⼀覧画⾯で☆の存在を確認する p NavigationDrawerを開いて お気に⼊り⼀覧画⾯に切り替える p お気に⼊り⼀覧画⾯で リストアイテムの存在を確認する 64 デモ

Slide 65

Slide 65 text

1.イントロダクション p 効率的にテストを書くこと p 変更に強いテストを書くこと 2.Espressoの基本 3.Espresso Test Recorderとその限界 4.実践!変更に強いテストを効率的に書く p サンプルアプリについて p テスト⾃動化対象の選定 p 操作・検証の記録 p 修正 65

Slide 66

Slide 66 text

覚えておきたいIDEのテクニック 66 コマンド Mac Windows Extract Variable Cmd+Opt+V Ctrl+Alt+V Extract Method Cmd+Opt+M Ctrl+Alt+M Inline Cmd+Opt+N Ctrl+Alt+N Move Line UP Ctrl+Shift+↑ Alt+Shift+↑ Duplicate Line or Selection Cmd+D Ctrl+D Generate Cmd+N Alt+Insert Help>Find Action... で⼊⼒!

Slide 67

Slide 67 text

修正⽅針(Recorder出⼒結果を参考に) Recorder出⼒で、動かない箇所を修正する (RecyclerView関連) p CheckBoxのトグル p RecyclerViewActions.actionOnItemAtPosition() はアイテムビューそのものしか操作できない Ø 独⾃実装のclickDescendantViewWithId() を使ってアイテムビューの⼦孫を操作 (サンプルではRecyclerViewUtilsクラスで定義) 67 タイトル1 操作できる 操作できない デモ

Slide 68

Slide 68 text

修正⽅針(Recorder出⼒結果を参考に) Recorder出⼒で、動かない箇所を修正する (RecyclerView関連) p CheckBoxの状態確認 p 指定positionのアイテムビューを検索するAPI が無い Ø 独⾃実装の withItemViewAtPosition(recyclerView, pos) で実現 68 デモ

Slide 69

Slide 69 text

修正⽅針(Recorder出⼒結果を参考に) Recorder出⼒で、動かない箇所を修正する (RecyclerView関連) p CheckBoxの状態確認 Ø withItemViewAtPosition()とisDescendantOfA() を使って更に下の階層にあるCheckBoxを検索 allOf(isDescendantOfA(root), target) → root配下のtargetを検索する Ø 事前にRecyclerViewActions.scrollToPosition() でアイテムビューを画⾯に⼊れておく 69 デモ

Slide 70

Slide 70 text

修正⽅針(Recorder出⼒結果を参考に) Recorderのおかしな出⼒を修正する (RecyclerView関連) p リストアイテムの存在・不存在確認 p CheckBoxの状態確認と同様 p 事前にRecyclerViewActions.scrollToPosition() でスクロールしておくのを忘れない 70 デモ

Slide 71

Slide 71 text

修正⽅針(Recorder出⼒結果を参考に) 以下のメソッドを切り出す(int引数は位置) 71 メソッド 概要 goArticleList() 投稿⼀覧ページへ goFavsList() Fav⼀覧ページへ toggleFavStatus(int) Favボタンのトグル assertFavStatus (int, boolean) Favボタン状態確認 assertItemExists(int) リストアイテム存在確認 assertItemDoesntExist (int) リストアイテム不存在確認 デモ

Slide 72

Slide 72 text

テストケース実装 さきほど定義したメソッドのみを使って、 テストケースを実装する 1. ☆をタップすると★に切り替わること 2. ★をタップすると☆に切り替わること 3. お気に⼊りが0件の状態で、☆をタップし て★にすると、お気に⼊り画⾯の表⽰件数 が1件になること (1件⽬が存在し、2件⽬が存在しないこと) 72 デモ

Slide 73

Slide 73 text

補⾜: RxJavaの待ち合わせについて 対応⽅法は諸説ある Schedulers.io()のみ利⽤の場合は③が良さそう ① RxAndroidのIssue #149 (結論は無いがサンプルコードあり) https://github.com/ReactiveX/RxAndroid/issues/149 ② RxEspresso (sub/unsubをカウントする) https://github.com/stablekernel/RxEspresso ③ Retrofitting Espresso (Schedulers.io()をAsyncTaskに差し替え) https://goo.gl/2p3E6S 73

Slide 74

Slide 74 text

補⾜: Espresso-Commons 今回紹介した⾃作ユーティリティだけ切 り出したものを 「Espresso-Commons」 として公開しています。 https://github.com/sumio/espresso-commons 74

Slide 75

Slide 75 text

ここまでのまとめ 変更に強いテストコードを効率良く書く⽅ 法を実演を交じえて説明しました 1. 「Espressoで簡単に記録できる or 書ける」 という観点でテスト⾃動化対象を決める 2. テストに必要な操作・検証をRecorderで 1回だけ記録する 3. 動かない出⼒を修正する 4. 操作・検証単位でメソッド抽出する 5. 抽出したメソッドのみを使ってテストを書く 75

Slide 76

Slide 76 text

最後に 変更に強いテストコードを効率良く書くに は、終盤で実演したアプローチに加えて、 知識や経験(引き出しを増やす)も重要です。 今回紹介したテクニックを⼟台に、まずは 1つ書いてみることをおすすめします。 ある程度軌道に乗ってから、 「難易度が⾼いが効果も⾼い箇所」 に挑戦するのがおすすめです。 76

Slide 77

Slide 77 text

END ご清聴ありがとうございました! 77