過去、 EarlGreyが出たての頃に試してみた のですが、最近またプライベートで使ってみたので自身のために残しておきます。
- 対象のproject: https://github.com/KazuCocoa/MyGithubSearch
- 対応コミット: https://github.com/KazuCocoa/MyGithubSearch/commit/bd83bf8668260978ec6941bd8c003470c9443167
幾つかサンプルではなくて自分で使ってみて、Appiumとの使い分けやテストレベルの対応などもある程度私の中で腑に落ちた感じがしました。
EarlGreyについて
EarlGreyは、XCUITestみたいに描画要素に対して何らかの操作を行うライブラリです。面白いのは、 UIView をハックしてなにか操作を模倣するのではなく、 UIAccessibility Protocolを操作する。
リポジトリはこちら。
https://github.com/google/EarlGrey
EarlGrey自体の説明はあるのでここでは書きません。
- セットアップ、導入
- Swiftサンプル
何か困った時
使えるAPIや、使い方がわからないとか、そういう時はテストコード読んだりAPIドキュメント見るとある程度対応できます。
- APIドキュメント
- Matcherの実装
– どのように動作しているか、といった説明も書かれているので、ざっと一読することをお勧めします
– https://github.com/google/EarlGrey/blob/master/EarlGrey/Matcher/GREYMatchers.h
– AccessibilytLabelやidentifierの他にも、Valueなど多くの要素が使えるのよいですね
– ただ、We strongly recommend using an accessibility identifier as it uniquely identifies an element.と書かれているように、やぱりaccessibilityIdentifierを使うことが良いことには変わりなさそう。ここは激しく同意。
Other Tips
- 要素を見つけたい時
- シミュレータだと、AccessibilityのAccessibility Inspectorを有効にしてそれを使うと良いです
- Appiumだとinspectorを使ったりPonyDebugger使ってたのですが、このAccessibility Inspectorが実は一番楽なのかも？
- Search Fieldなどで”Search”をしたい(テキスト入力後の決定)
\nをgrey_typeTextで入力しましょう。そこを契機にkeyboardの”return”や”search”になる箇所の操作と同じ動作をします
シナリオの記述例
以下、Searchフィールドをたっぷ、”KazuCocoa”と入力して決定、検索するというシナリオです。
selectElementWithMatcherで要素を見つけ、performActionで何か操作をし、assertWithMatcherで要素をチェックする。- EspressoのViewMatcher、Perform、Assertの形と同じですね。Googleではこういう形での記述に統一しているような雰囲気を得ます。
| import XCTest | |
| class MyGithubSearchEarlGrey: XCTestCase { | |
| let eg: EarlGreyImpl = EarlGrey() | |
| override func setUp() { | |
| super.setUp() | |
| } | |
| override func tearDown() { | |
| super.tearDown() | |
| } | |
| // See more example: https://github.com/google/EarlGrey/tree/master/Tests/FunctionalTests/Sources | |
| func testExample() { | |
| // Can identify value with "grey_accessibilityValue" | |
| eg.selectElementWithMatcher(grey_accessibilityValue("Search")) | |
| .assertWithMatcher(grey_sufficientlyVisible()) | |
| // see if you would like to know keyboar handling | |
| // https://github.com/google/EarlGrey/blob/master/Tests/FunctionalTests/Sources/FTRKeyboardKeysTest.m | |
| // You can check the target is value/accessibilityIdentifier/accessibilityLabel and so on via inspector provided by iOS. | |
| // But using accessibilityIdentifier is strongly recommended. | |
| // new line "\n" is "resutn" of keyboard | |
| eg.selectElementWithMatcher(grey_accessibilityValue("Search")) | |
| .performAction(grey_tap()) | |
| .performAction(grey_typeText("KazuCocoa\n")) | |
| } | |
| } |
具体的には以下。
Appiumとの使い分け
ざっくりと書くと、ツールの使い分けは以下な感じ。Quickなどはありますが、やはりSwiftでシナリオベースのテストコードを書くのは面倒です。なので、本当にその視点から記述したシナリオベースのテストを残しておきたいなら、私はAppium + Rubyをベースにしたものをつかたいと思います。
- Appiumを使うとき
- シナリオを記述したテストコードの実行
- ネットワークキャプチャなどのアプリ全体を操作したい時
- EarlGreyを使いたい
- CIに組み込む
- 限定的な操作を安定して早く実施したい
- イメージとしては、単一の機能であったり、境界値によってViewが変化するような隅っこのチェック
- Layoutをチェックしたい(image diffではない)
image diffなんかは単なるassertionの手段なので、必要に応じて使いましょう。
こういうのを、社内で置いているテストレベルと照らし合わせながら導入できると雑多にはならなさそうですね。
XCTest -> EarlGrey -> Appium
という感じで、ロジックのチェックからGUIのチェック、アプリ全体の計測まで進んでいくと順当そう。
ちょうど、テストサイズをベースにするとS/M付近がXCTest、M/L付近がEarlGrey、L/EがAppiumという感じの関係性でしょうか。
締め
あまり情報がないですが、やはり短時間で成果を出すにはこの手のテストコードも素早く安定させた形にすることが必要です。その上で、この手ではできないことを人が実施する。
そのためにはこういうツールやテストの構築方法含め、フルで知見を導入していきたいですね。
