XCTestでUITestするやり方

公式ドキュメント - User Interface Testing
UITestする時、view（XCUIElement）を特定する方法は2つ

1.accessibilityIdentifierを指定して一意にする

self.hogeButton.accessibilityIdentifier = "hogeButton";

2.viewのインデックスや、表示されている文字列から特定する

let tablesQuery = XCUIApplication().tables
tablesQuery.cells.staticTexts["ほげほげ"].tap()
tablesQuery.cells.elementBoundByIndex(0).tap()

1.が推奨だけど、テストしたい画面のviewにいちいち指定するのが大変。

また、UIRecordingで作られるのは主に2.のようなコード。

なので、基本的に2.でテストコードを書いてみて、viewを特定するのが難しかったら、1.でやってみることにした。

UITestするとき便利なもの

UIRecording

割愛、下記を参照
- http://qiita.com/IsaoTakahashi/items/f9c3ef367d7e0f60e2d6

Gather Code Coverage をオンにする

オンにすると、Test Reportsが生成される
Test Reportsの目玉マークを押すと、テスト中のスナップショットが閲覧できる
テストに失敗したときどの処理で失敗したのか、とても見やすく見つけやすい
テストを重ねると、スクショが溜まって、ディスク容量がいっぱいになるので注意
やり方は下記のスライドの32ページからが１番わかりやすい
- http://www.slideshare.net/nowsprinting/20150711-ui-testinginxcode7

appium の inspector

これがあると、実機でテストしたい画面を表示させて、viewの要素を階層ごとに把握できる
セットアップや使い方は、下記の動画を見るのが１番楽だった
- https://www.youtube.com/watch?v=meU4TzI3KNM
一つ注意なのは、実機で inspector を表示するには下記が必要
- brew install ideviceinstaller

Xcode の Debug View Hierarchy

公式ドキュメント - Examining the View Hierarchy
Debug View Hierarchyで表示できない画面はviewが多すぎて、viewの特定に時間がかかり、テストに失敗することが多い（たまに成功する）
Debug View Hierarchyで表示されない画面のUIテストは失敗率が高い（accessibilityIdentifierを指定しても）

先人の知恵

UITestするときに困ったことと、その解決策

cell や button をタップしてくれない時がある

Failed to scroll to visible (by AX action) ・・・の場合
- http://stackoverflow.com/questions/33422681/xcode-ui-test-ui-testing-failure-failed-to-scroll-to-visible-by-ax-action
Failure fetching attributes for element ・・・ の場合
- Xcodeのデバックエリアで po XCUIApplication().tables.cells.elementBoundByIndex(0).buttons["ほげほげ"]とかすれば、対象のviewは一応特定できるがテストを実行すると失敗することが多い（たまーに成功するから厄介）
- このエラーが出る画面では Debug View Hierarchy でおそらく表示できないので、viewが多すぎて XCUIElementQuery で探せないのが原因なのだと思う
- 画面のUIを考え直すか、テストを諦めるか・・・

タップやスワイプなどのイベント動作が遅い

Failed to get refreshed snapshotというエラーが出る
viewが多すぎるのが原因だけど、UIPickerのnumberOfRowsInComponentで返す値が大きすぎると出る
- http://stackoverflow.com/questions/35977575/failed-to-get-refreshed-snapshot-error-when-ui-testing-with-a-uipickerview

TextView や TextField にうまく文字が入力出来ない時

keyboardType に UIKeyboardTypeEmailAddress を指定しているとき、日本語だとたまにキーパットではなく、フリック入力のキーボードが立ち上がることがある
これだとtest@test.comみたいなアドレスを入れたい時、てst@てst.comみたいになるので困る
ダブルタップしてペーストすれば入力自体は可能
- http://stackoverflow.com/questions/32712036/xcode-ui-testing-typing-text-with-typetext-method-and-autocorrection

非同期処理などでviewが表示されるのを待ちたい

広告表示、APIの取得 etc で表示が遅れるとき
waitForExpectationsWithTimeoutを使う
- http://masilotti.com/xctest-helpers/

NSTimerなどのテストで遅延したい時

ストップウオッチがある画面などのUIをテストする時、一定の時間待ってからボタンをタップとかしたい
waitForExpectationsWithTimeoutとdispatch_afterの組み合わせでやる
例えば、開始ボタンを押すと、開始ボタンが一時停止ボタンになり、一時停止を押すと再開ボタンに変わる、みたいなストップウオッチ画面の場合

ストップウオッチのボタンの移り変わり

例「ストップウオッチのテストのために60秒遅延させる」


・・・

let app = XCUIApplication()
app.buttons["開始"].tap()

// ストップウオッチのテストのために60秒遅延
let timeout:Double = 60
let dispatchTime: dispatch_time_t = dispatch_time(DISPATCH_TIME_NOW, Int64(timeout * Double(NSEC_PER_SEC)))
dispatch_after( dispatchTime, dispatch_get_main_queue(), {

    app.buttons["一時停止"].tap()
    app.buttons["完了"].tap()
});

// 再開ボタンが表示されるまで（一時停止が押されるまで）待って、後続の処理を遅延
let existsPredicate = NSPredicate(format: "exists == 1")
expectationForPredicate(existsPredicate, evaluatedWithObject: app.buttons["再開"], handler: nil)
waitForExpectationsWithTimeout(timeout + 3, handler: nil)

・・・

XCTestでUITestを書いてみて

複雑な画面でなければ失敗することは少ない感じ
Debug View Hierarchyで表示できない画面は、UIを考えなおす必要がありそう
初期コストはとても高いですが、一度書いてしまえば後がとても楽（それがテストというもの）
EarlGreyなどのOSSを使うと、人によっては初期コストが少し下がるかもしれません
appiumなら、クライアントもサーバーもテストが全てRubyとかJavaにできるので、お好みで

XCTestでUITestするとき便利なもの、困ったこととその解決策