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

Copyright © DeNA Co.,Ltd. All Rights Reserved.

iOS Test Night #12016/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アプリの自動テストをはじめよう

Technology