この投稿は Sansan Advent Calendar 2015 の 22 日目の記事です。
みなさんテスト書いてますか？
テスト書くの面倒ですよね。
UI テストは特に面倒なことが多いと思います。
iOS アプリの UI テストを KIF → Appium に乗り換えた(ている)ので、その話を書きたいと思います。
それぞれのテストフレームワークについては詳しく説明しておりませんので、ご了承ください。
テストでやりたいこと << KIF でできること だった
KIF は以下の様な特徴を持った UI テストフレームワークです。
- Objective-C/Swift でテストコードを書ける
- Xcode からテストを実行できる
- プロジェクト内にテストコードを書くので、Mock, Stub 等の別ライブラリとの相性が良い(参考: KIFとNLTHTTPStubServerを利用して最低限のIntegrationTestを実現する)
Stub を用いて、通信結果を差し替えることで複雑なテストパターンを再現可能であることや、既存コードとの親和性が高いということが、KIF を選定した理由です。
ただ初めは意気揚々とテストコードを書いていけたのですが
- テスト対象のアプリが Android にも展開しているアプリであったことから、双方で同じテスト書くのがもったいない
- テストコード量が大きかったので、画面改修/仕様変更により通らなくなるテストパターンが出てきて辛くなった
といった理由から、より費用対効果の高い方法はないか模索し始めました。
そして Appium へ
UI テストを再度書いていくに当たり、まずメンテナンスコストが低く、効果が高い箇所をテスト対象に絞ることにしました。そのうえで、Android とテストを共通にすることができる Appium でテストを書き直すこと。
Appium は以下の様な特徴を持ったテスト自動化フレームワークです。
- Ruby, JavaScript, Python といった様々な言語で書ける
- プロジェクト内にコードを追加する必要がない
- iOS/Android 双方のアプリのテストコードを共通化できる
KIF と比べてプロジェクト内のコードを参照できないため、テストできることはシンプルですが、最低限確かめたいことには十分であったことと、なにより Android とテストが共通化できることのメリットが大きかったため、Appium を採用しています。
まとめ
何をテストしたいのか、テストの目的は何かをチームで話し合い、目的にあったフレームワークを選定できると良いですね。