既存のiOSプロジェクトにUI自動テストを実装したの話
実装したアプリはWebAPIを使用したストレージアプリで、取得してきたデータをTableView(またはCollectionView)で表示する画面が複数あります。
開発人数は2名で別に品質管理チームがおり、品質管理チームにテストして貰う前に、UI自動テストを行うという目的です。
環境
- Xcode version 7.x
- KIF version 3.3.0
kif-framework/KIF: Keep It Functional - An iOS Functional Testing Framework
どこまでUIテストを行うか?
自動UIテストの範囲は広くどこまでやるかが明確ではないため、最終的に組み込まれたものと、そうではないものに分けて記載します。
自動テストしたこと
- シェルスクリプトを起動するだけすべてのUIテストが完了するようにする
- デバイスごと動作することを確認する(iPhoneとiPad)
- バージョンごとに動作することを確認する(iOS9とiOS8)
- ユーザー名、パスワードを入力してログインできる
- すべてのボタンが表示されていることを確認する
- すべてのボタンが動作されていることを確認する
- 検索が動作されていることを確認する
- アラートを表示は確認する
- TableViewに表示されている文字を確認する
- テスト中にスクリーンショットを保存する
複数デバイスで起動するためはxcodebuild
をシェルスクリプトで起動するようにする必要がありました。
UIテストは開発者視認できないほど早く動作し目視の確認が難しいため、テスト時にスクリーンショットを保存するのは有効です。 またスクリーンショットをフォルダ別にデバイス名、iOSバージョン、アプリバージョンを記載することで、バージョンごとの画面ログとして効果があります。
すべてのUIテストはファイルごと独立して動くようになっています、これはKIFでUIテストの順番を指定できないためです。
例えばLoginUITest.swift
とLogoutUITest.swift
があるときにLoginUITest.swift
が先にテストされるとは限りません。
そのためLoginUITest.swift
のはじめにログアウト処理、LogoutUITest.swift
がのはじめにログイン処理を入れてあります
自動テストしなかったこと
- ネットワークエラー時
- 画面数xネットワークエラー数は数が多くなりすぎる上にエラーテストとUIテストを同時にやるのは難しい
- ログイン時のユーザー名、パスワード入力のエラーケース
- 上記と同じくエラーケースが多いので、ほとんどやらなかった
- ユーザーが開発者が想定外の操作をするケース
- ボタンに対して連続タップをする、高速でスワイプをするなどのケース
- 操作後に正常であることを示すテストが難しかったため
- ボタンに対して連続タップをする、高速でスワイプをするなどのケース
例外処理時のテストを実装するにはかなり時間がかかり、ほとんど実装はしませんでした。
KIFで発生した問題
日本語のキーボードは無効にしておく
- 試験をしているとシミュレーターの入力モードが日本語になってしまうことがあったので、日本語入力にならないように設定を変更しました。
- シミュレーターのiOSのSettings > General > Keyboard > で Japanese-Kana を削除
連絡帳へのアクセスを許可しますか?
などのシステムアラートは検知できないことがあるtester.acknowledgeSystemAlert()
が動作しないことがあります- 解決法が無いですが、予めシステムの許可を設定するか、目視でタップする用にしていました
UIテストの起動に失敗する
エラーログも出ないことがあるxcodeを再起動することで、起動できたりもします
表示されているUIが検知できないでテストが失敗する
- XCTestでも発生する、現状で有効な回避方法はないと思います
実装後の感想
- 今のところスマホのUIテストにベストプラクティはないので、手探りでやるしかない
- 状態遷移が多いアプリはテスト作成に非常に時間がかかる
Unitテストと違い、UIテストを必須にすることは非常に難しい
メリット