iOSアプリの自動テストをはじめよう

Copyright © DeNA Co.,Ltd. All Rights Reserved.
iOS Test Night #1
2016/11/18(Fri)
平田敏之@DeNA
iOSアプリの自動テストを
はじめよう

自己紹介
 平田敏之@DeNA
⁃ 経歴
• GWの開発 → ホムペサービスの開発、iOSアプリの開発 → SWET
⁃ SWET(Software Engineer in Test)
• 事業サポートチーム / テスト基盤チーム
• ミッション
⁃ DeNAサービス全般の品質向上
⁃ DeNAエンジニアの開発生産性向上
⁃ 私がやっていること(の一部)
• クライアントアプリ周りのテスト戦略、自動テストの開発
• CI/CD環境整備
• テスト基盤環境の開発

今日の発表の流れ
 本日のプロローグ
⁃ iOS Test Nightを開催した理由
 本日のメイン
⁃ iOSの自動テストをはじめるにあたって
• 自動テストを書く際におきがちなこと
• どうやって自動テストをはじめるか

iOS Test Nightを開催した理由
 iOSにおけるテスト周りに関する情報がまだまだ少ない(と感じている)
⁃ Qiitaのキーワード検索結果(11/18時点)
• XCTest: 159
• XCUITest: 10
• EarlGrey: 3
• Espresso: 127
• Appium： 124
• JUnit: 866
• RSpec: 1728
• fastlane: 113
 しかし、興味はあるはず(と信じている)
⁃ 参加者が少なかったらどうしようと震えながら本勉強会を開催しました
 勉強会を開催すれば知見が共有できて良い循環がまわるはず

IOSの自動テストをはじめるにあたって
主な対象ユーザ：
これから自動テストを書こうかなと思っている人
コンテンツ
1) 自動テストを書く際におきがちなこと
2) どうやって自動テストをはじめるか

自動テストを書く際に起きがちなこと
いきなり闇雲に自動テストを書いてもうまくいかないことが往々にしてあります

自動テストを書く際に起きがちなこと
闇雲に書きはじめると以下の様なことがおきたりします
 意味のないテストコードを書く
⁃ テストになっていないテスト
 読めないテストコードを書く
⁃ 可読性が悪く何をしているのかが分からない
⁃ なんのテストをしているのかが分からない
 自分の環境でしか動かないテストコードを書く
⁃ 他の人の環境やCI上では動かない
 テスト結果が分かりづらくなるコードを書く
⁃ テストが落ちたときの調査が大変
 無駄な(不必要な)テストコードを書く
⁃ テストの実行時間だけが増える

自動テストを書く際に起きがちなこと(1/3)
 意味のないテストコードを書いてしまう
 例）テストになっていないテスト
⁃ 自動テストで確認する箇所が不適切
• UIテストでいえば要素が「存在する」のか「叩ける」のか etc
• 手動用のテスト項目を自動テスト化すると発生しがち
⁃ 手動用のテスト項目は曖昧に書かれていることがある
⁃ 失敗することがないテスト
• 常にgreenになる

 テスト結果が分かりづらいコードを書いてしまう
 例）使うべきAssertionが不適切
⁃ XCTAssertTrue(expression1== expression2)
• Xode
• JUnit x Jenkins
⁃ XCTAssertEqual(expression1, expression2)
• Xode
• JUnit x Jenkins

 無駄な(不必要な)テストコードを書いてしまう
 例）パラメータだけを変えたテストを「無駄に」増やす
• どのテストレベルでも起こりうる
• 境界値や同値とかを意識していない
⁃ 「自動テスト」だからといってむやみに増やすケースがある
 その結果、実行時間の増加につながっていく

おとずれる自動テストとのお別れ
 テストの実行結果からコードを追うのが大変
 可読性が悪くコードを読むのに時間がかかる
 どのようなテストをしているのかがわからない
 テストコードを直すコストが高すぎて失敗が放置される
失敗したまま放置されだすと
• 割れ窓理論(1つがredになりだすと..)
• 聞こえてくるこわい声
⁃ 「この落ちているテストは落ちてて問題ないテストです」
⁃ 「とりあえずredなのを全てdisableにさせておこう」
そして自動テストは放置され価値を無くし、
「自動テスト＝良くない」という認識が..

自動テストをはじめるにあたって
「どこから」「どこまで」「どうやって」やるかを考えましょう

そもそも「テスト」とは？
よく言われることですが、
 テスト自体はプロダクトの「品質」をあげてはくれません
 現時点での品質が「わかる」だけです
 その品質を良くするのは自分たちです
 テストは、その良くしようとする行為を支えてくれます
⁃ 適切な自動テストは力強く支えてくれます

まずはじめに
闇雲に書き出しても求めているものは得られません
 まずは以下の3つを考えましょう
⁃ 「どこからやるか」
⁃ 「どこまでやるか」
⁃ 「どのようにやるか」

「どこから」やればいいですか？
まず書きはじめるところを見つけましょう
 Unitテストで基盤といえるControllerに関わるModel周り
 UIテストでアプリで共通となっている画面フロー周り
⁃ ログインがあるアプリならログイン周りだけやるという手も
 あなたが不安を感じているところから
⁃ 開発者の不安は当たります
• ただし不安なところはテストコードが書きづらいことも多い
 バグを修正するタイミングで該当機能に対して
 新機能追加のタイミングで新機能に対して

「どこまで」やればいいですか？
 最初からやりすぎようとしない
⁃ やりすぎると息切れをおこす
⁃ カバレッジ100%とかを意識しすぎない
 まずは小さく「はじめる」のが良い
⁃ 小さく作って運用にのせていく
• CI環境で動かせるようにするのが良い
 運用に乗り始めてから少しずつ改善していく
⁃ テストの網羅性
⁃ テストの実行速度
⁃ アプリのバージョンカバレッジ
⁃ OSカバレッジ
⁃ 画面カバレッジ

「どのように」やればいいですか？
 テスティングフレームワークの選定
⁃ XCTest / Quick etc
⁃ XCUITest / EarlGrey / Appium etc
 テストコードを書く際には以下の点に注意
⁃ テストの独立性
⁃ テストの再現可能
⁃ テストが繰り返し可能
⁃ テストが自分の環境以外でも動く
 文化を育てるためにも
⁃ サンプルとなるコードをしっかりと用意
• 他の人がはじめやすいようにする
⁃ 実行結果などの見える化

iOSの自動テストのために付き合う必要があるもの
 テスティングフレームワークのバグ
⁃ XcodeのRelease Notesの「Testing」のコーナを見るようにしま
しょう
• 既知のバグに対するworkaroundがのってたりもします
 バージョンアップ対応
⁃ Xcodeのバージョンアップに対応する必要があったりもします
• 例) Xcode8.1のRelease Notesより
⁃ UI tests may fail to run for apps written with Swift 2.3

自動テストのステップ例
どのようなステップですすめていくかの例
 セットアップ
⁃ 自分のマシンのセットアップ
⁃ CI環境のセットアップ
• 誰もが見れる環境でも動かせるようにする
• fastlaneを使うのが良い
⁃ セットアップのためのREADMEを用意
 テストコードの実装
⁃ テストを書くところを決める
⁃ テストを書く
⁃ 書いたテストをCI環境で動かす
• PR状態のbranchで動かし続けるのが良い

「自動テストをはじめましょう」
iOSに根を下ろし、Appleと共に生きよう
テストと共にリリースを乗り越え
ユーザと共に新バージョンを歌おう
ラピュタより

さいごに
 「どこから」「どこまで」「どうやって」を考えて、是非テストをはじ
めてみてください
 テストをはじめて得た知見をiOS Test Nightで是非発表をしてください
 その話を聞いた人がその知見を元に新たな知見を得て発表をしてくれる
と思います
⁃ これが幸せなループになると思っています
 皆様の応募をお待ちしております！！

iOSアプリの自動テストをはじめよう

More Related Content

What's hot

Similar to iOSアプリの自動テストをはじめよう

More from Toshiyuki Hirata

iOSアプリの自動テストをはじめよう