UIテストと上手く付き合えてますか? 「UI Test の楽しさとメリット」 #tryswiftconf

はじめに

モバイルアプリサービス部の中安です。

さて、昨日からブログにしたためていますが、今年の try! swift Tokyo に参加させていただいております。

今回は昨日のセッションのレポートを書かせていただきます。

講演概要

公式ページからの引用

UI Test の楽しさとメリット by Sarah Olson

多くのiOS開発者はユニットテストには精通していますが、Xcodeを使ったUIテストを行なっていない方が多いと思います。自分のアプリに UI テストを導入した際のハイライトと、すべてをテストすることの苦労を共有します。

スライド資料

内容

Trelloのアプリ開発に携われているサラ・オルソンさんの講演でした。

自分がこの講演に注目した理由は、自分自身があまりUIテストのコードを書いた経験がないというところからでした。 なので、前線でやっておられる方がどのようなテストの方法を行われているのか気になりました。

話は経験談から

内容はWWDCでXcodeでUIテストのサポートが発表されたところからの経験談が主だったかと思います。

UIKit+MVCアーキテクチャから地道にやってみようとしたが断念したこと。 待ちに待ったサポートだったけれど、バグの多さや仕組みの複雑さに当初はガッカリした部分も多かったという話もされていました。

XCUITestでテストするにあたっての制約

Trelloのチームで試された中でXCUITestによるテストが厳しかったことは以下になるそうです。

• Watchに対するテスト
• Siriのテスト
• Translation / 多言語を使用するのでUILabelの表示結果テストは工夫が必要(と言っていた気がする)
• アニメーションテスト

実践されていること

• 自動的なスモーク(リグレッション)テスト
• モックAPIを使う
• スナップショットテスト

感想

「楽しさ」というタイトルがあったので、苦労した部分の改善策、幸せになれた手法的なものについてはもう少し実例で見たかったなというところでした。

あとは、大きくデザインが変わるときなどは、テストの扱いはどうなるのかなというのも少し思ったところです。

UIテストは人力で行えば何個もアクションが必要なところを省略し、正確性の高いオペレーションの中でアプリを試験できるものです。 なので、取り入れる場面というのをきちんと取捨選択、ただしく運用すれば非常に強力な手助けになるはずです。

チームで開発するなら、カバレージの範囲のことなどを事前にちゃんと話し合ったほうがよさそうです。