KIFテストの注意点やセオリーについて

現在1ヶ月の夏休みを満喫している sfumiharu です 😛
日頃はスクラムチームにて主に iOS, Android のハイブリッドアプリのQAをしています。

前回、KIFの導入からKIFテストを実行するまでのエントリを投稿させて頂きました。
その際、書き忘れてしまった事が何点かあったので、今回はその補足エントリとなります。近年稀に見る纏まりのない、話の流れもないエントリとなります。ご容赦下さい。

流れ

  1. KIFのおさらい
  2. 非公開APIに触れている…
  3. テストの記述場所について
  4. テストメソッドの名前について
  5. テストの記述について
  6. テストの実行順番

KIFのおさらい

  • KIF は カード決済で有名な Square 社が Github 上で無料公開している iOS の UI テストフレームワーク
  • pod install で気軽にプロジェクトに組み込める
  • タップ, 入力などのテストをシーケンシャルに書いていくので、テストの流れを理解しやすい
  • KIFはXcodeとの連携が強力で、ショートカットで簡単にテストを実行できたりする
  • KIFテストはシミュレータ、実機で実行できる

 

非公開APIに触れている…
KIFは非公開APIに触れています。その為、メインスキームでKIFが実行される設定だとストアレビュー時にリジェクトされる恐れがあります。KIFを導入する際は、メインスキームとは別に、KIFテストを実行する為のスキームを作りましょう。こうする事でストアレビュー時のリジェクトリスクを抑えます。

テストの記述場所について
KIFテストは、KIFTestCaseクラスを継承したクラスに記述します。
KIFTestCaseクラスはXCTestCaseもしくはSenTestCaseクラスを継承しているので、XCTAssert等のアサート系メソッドもKIFメソッドと併せて使えたりします。
メソッドの詳細については公式ドキュメントを御覧ください

テストメソッドの名前について
メソッド名の頭は test とし、戻り値の型は void にします。
Prefixをtestとする事で、このメソッドはテストなんだ とXcodeが認識します。
認識すると、メソッドの頭にひし形マークが現れます。
ひし形マークをマウスオーバーすると、再生マークが現れ、クリックするとそのテストのみ実行されます。

before after

テストの記述について
KIFテストは、タップする、入力する、スワイプする などのテストステップの前に、待つというwait系のテストステップを記述するのがセオリーとなっています。wait系メソッドを用いることで、遷移や読み込みによる画面間のズレ等を吸収し、機能不全以外でのしょーもないFailを極力防ぎます。

例えば、postButtonというアクセシビリティラベルが設定されているボタンをタップしたい というテストを書く場合、以下のようになります。

-(void) testShowLionView{
[tester waitForTappableViewWithAccessibilityLabel:@"postButton"];
[tester tapViewWithAccessibilityLabel:@"postButton"];
}

ちなみに、testerとは、KIFUITestActorクラスのインスタンスへのショートカットで、defineで定義されています。KIFUITestActorにはタップや入力などのユーザーアクションメソッドがひと通り定義されています。アクセシビリティについては、そもそも知視覚障害者の為の機能で、これを用いてタップなどのユーザーアクションを実現します。postButtonというアクセシビリティラベルが設定されているエレメントの座標位置やフレームサイズを取得し、それらからエレメントのセンターポジションなどを計算し、エレメントタップを実現しています。

このように、基本的には wait + tap etc という組み合わせでテストを書いていきます。

テストの実行順番
Command + U で全てのKIFテストを実行した際のテストの実行順番についてですが、順番としてはアルファベット昇順で実行されます。現在のところ、このルールを変更することは出来ません。その為、テストを追加していく毎に実行順番が複雑になり、最終的にどの順番でテストが実行されるのか解らなくなってきたりします。命名規則でカバーするのは現実的ではない為、基本的には、どのテストがどの順番で実行されてもいいような、実行順番に左右されないテストを書くのが良いでしょう。

しかし、テストの為の前準備や、テスト実行前/後に行っておきたい事があったりすると思います。たとえばSNSサービスなど認証を要求するサービスの場合、事前に認証をしていないとそもそもテストが出来なかったりします。そのような場合は、以下4つの特別な働きをするメソッドを利用すると良いと思います。

beforeEach 各テストケースの前に呼ばれる
beforeAll 最初に1回呼ばれる
afterEach 各テストケース終了後に呼ばれる
afterAll 全てのテスト終了後に呼ばれる

あと、例えば、AさんとBさんが友人関係になるテストで、まずBさんがAさんに友人申請を送り、Aさんは一度却下します。再度Bさんが友人申請を送り、Aさんが承認する。といったテストを書くとします。この場合、事前に必ず友人申請を送らなければなりません。この様な場合であれば、以下の様にテストを書いても良いと思います。

-(void) friendRequest{...}
-(void) friendRequestDisagree{...} 
-(void) friendRequestAgree{...}

-(void) testAddFriend{
[self friendRequest]; 
[self friendRequestDisagree]; 
[self friendRequest]; 
[self friendRequestAgree]; 
}
友人申請部分のテストも1つに収まって良いですね 😛
.
.
言いたいことは以上になります。
言いたいことが言えたところでKIFの今後的なお話を1つ。

.
現在KIFは、ボタンをタップするなどのユーザーアクションのテストしか行えませんが、そう遠くないうちに視覚チェックも行えるようになると思います。正確には、
UIテストフレームワーク上で動くLelaというフレームワークが視覚チェックを実現してくれます。LelaはKIFと同じくSquareの中の人が作りました。当初はKIF-NextというKIFから派生したUIテストフレームワーク上でのみ動いていましたが、KIFでも動かせるようにしよう!という熱がコミュニティ内で上がってきています。実際にLelaを触ってみましたが、設定、実装ともに簡単で数分あればレイアウトチェックができるようになります。

demo は github にありますの。KIFの設定が面倒という方はどうぞ – https://github.com/sfumiharu/ques