Appiumのテスト失敗時の修正をちょっとわかりやすくする

こんばんは。Selenium/Appium Advent Calendar 2017の15日目の記事です。

多くのエンジニアの方々は、テスト失敗時の問題修正に時間を使っていることかと思います。それはテストコードの問題なのか、製品コードの問題なのか、はたまた別な問題なのか。

そのため、例えばテスト失敗時のエラー情報から、再度テストを実行することなく、どのように修正すれば治るのか、どうなおせば良いのかを教えてくれるとその時間を減らすことができますね。(これに似た話は色々と目にしますね)

今回は、Appiumを使った時の、そんな修正を便利にするちょっとしたアプリを共有します。

リポジトリはこちら => https://github.com/KazuCocoa/appium-source-viewer

テスト失敗時に取得する情報は何を取得する?

多くの場合、Appiumのようなツールを使う人はテスト失敗時にテスト対象のスクリーンショットを取得するかと思います。また、人によっては動画を取得する場合もあるでしょう。Appiumに限らず、GUIが関係する場合は特に、そのような情報を失敗時の情報として取得するでしょう。

では、テストを修正する人はその情報を見ただけでどのように修正すればテストがOKになるか判断することができますか?

表示されている文字だけを見ているのであれば修正できる可能性はあるでしょう。ただ、例えばAndroidだと resource-id 、iOSだと accessibility identifier を使うことが普通になっている場合は、スクリーンショットを取得したとしても該当しそうな箇所をその表示のみから追うのはキツいのではないでしょうか。ソースコードを確認し、再度繰り返し実行し、調整していくことも多いのではないでしょうか。

とても時間が勿体無いですね。 どこが失敗 し、 どう修正すべきか を教えてくれるテスト結果であれば、この時間は短縮でき、楽に問題を修正することができるでしょう。

Sourceも取得する

どこが失敗 し、 どう修正すべきか を知る手段として、テスト失敗時の情報として page_source の情報は1つの役立ち情報でしょう。例えば以下な感じのXMLです。

<AppiumAUT>
  <XCUIElementTypeApplication type="XCUIElementTypeApplication" name="UICatalog" label="UICatalog" enabled="true" visible="true" x="0" y="0" width="375" height="667">
    <XCUIElementTypeOther type="XCUIElementTypeOther" enabled="true" visible="false" x="0" y="0" width="375" height="667">
    ...
    ...
    </XCUIElementTypeWindow>
  </XCUIElementTypeApplication>
</AppiumAUT>

GoogleのEspressoやEarlGreyはテスト失敗時にそのように画面のヒエラルキー情報を出力してくれますね。そのおかげで、修正者は要素がそもそもないのか、ある場合はどのような情報を付与するとそれを特定できるのか、はたまた別な要素である必要があるのかを判断することができます。(XCUITest自体は残念ながら取得できないです(できなかったですよね…?))

スクリーンショット x source

sourceだけの場合、そのXML情報を想像できなければ結局は表示内容を確認することになるでしょう。

そこで役立つのがスクリーンショット。ただ、sourceとスクリーンショットを自分の目で照らし合わせることはそれはそれで慣れが必要です。

そんな時、例えばAppium-Desktopのようなツールを利用できたらどうでしょう? 視覚的にスクリーンショットから該当するsourceの要素を確認できる ようになり、だいぶ問題を見つけることが楽になるのではないでしょうか。

オフライン x スクシーンショット x source

便利だろうということで作って見ました。Appium Desktopを参考に、オフラインで使える形にしてみました。

sourceのXMLを読み込み、任意の要素をクリックすると、該当する要素がハイライトされます。逆に、スクショの任意の要素をクリックすると、該当するsourceのXML要素がハイライトされます。

sample

再度、リポジトリはこちら => https://github.com/KazuCocoa/appium-source-viewer

これを用いると、

例えばAndroidだと resource-id 、iOSだと accessibility identifier を使うことが普通になっている場合は、スクリーンショットを取得したとしても該当しそうな箇所をその表示のみから追うのはキツいのではないでしょうか。ソースコードを確認し、再度繰り返し実行し、調整していくことも多いのではないでしょうか。

に対して、失敗した情報からどのように修正すれば良いのかという内容を、より楽に見つけることができるでしょう。要素を特定する為にAppiumが必要とする情報がだいたい見られる為です。XPathのコピペは確か実装していないですが、XPathは不安定なこともあるので個人的には問題になってはいません。

使い方はREADMEに書いているのですが、 releaseからバイナリを取得して、macOSの Application ディレクトリに .app を移動し、アプリを実行してください。そこに、スクリーンショットへのパスと、sourceへのパスを指定、画面をreloadすると使うことができます。

著者の環境がMacなのでmacOSしか試していません。。。が、一応はElectron製なのでWindowsやLinux系列でも動くものをビルドすることはできるでしょう。(どなたか…)

最後に

というわけで、テストの失敗は、どう修正すればそれが治るのかということも知ることができるととても嬉しいです。その為に、ちょっとした便利アプリを必要なところだけ抜き出して作って見ました。

Advertisements

[Erlang][Software Test]Property-based testing/QuickCheck Testing

I often see Property-based testing recently, and the following article is useful to understand what property-based testing and quick check testing is I’ve read for a few years.

PropEr Testing
http://propertesting.com/

I use QuickCheck testing in my work, and it works fine against functions especially stateless ones.

Classification Treeの歴史

知らなかったので、メモ

[iOS]What’s new Testingを見た

What’s new Testingを見た。

https://developer.apple.com/videos/play/wwdc2017/409/

見ている途中でいくつかメモしたので、その記録として…


  • multiple appのテスト、URLを引数で与えることできるのね

20170612035154_img20170612-17-2kk0z7_480

  • Accessibility Dataのところで説明しているsnapshot、WebDriverAgentが使っているやつぽいな
  • おー。いちいちsnapshot取得する必要がなくなるのか。実行時間改善しそう

20170612035308_img20170612-16-1ng7xs0_720

20170612035501_img20170612-14-zvr8i3_720

  • 要素の検索で全捜査でなくて最初にマッチしたものだけさっと返すようにした、という話だけれど、ようやくという感じ。

20170612035637_img20170612-14-nebl01_480

  • ここら辺は元からそうなのでそうよねという感じだ。
  • ここはどこまで厳密に書くかはどれだけ内部実装と結合を強くするかの問題ですね。Espressoでも同じ問題をもつ。

20170612040244_img20170612-19-18xc35w_720

  • 地味に嬉しい

  • Activity styleの書き方、Cucmberとかイメージすると良さそう。stepsにいろんな処理を入れて、シナリオはstepsを並べて記述するような感じが使い方として近そうだ。

  • 非同期の奴も良さそう。XCTestなので、XCUITestでも使えるし。
  • snapshotのところはほんといろんな3rd partyも恩恵受けるだろうし、良いことづくしな気がする。けれど、これはXcode8でないと使えないOSテストするときは恩恵受けられないので、完全に恩恵を教授できるのは数年後かな…

Xcode9のいくつかの機能、Xcode9以前でも使えると恩恵大きくて良いな…

“~ility testing”, not “no-functional testiong”

“~ility testing” is preferred than “non-functional testing” since “non-functional testing” indicate only others.

I agree with the opinion because “non-functional test” already have many kind of test.

Watch “Test-Driven Development on Android with the Android Testing Support Library”

pick and past some key images to the following.

  • A famous test pyramid

20170519024718_img20170519-17-x25i39_720

  • Development Lifecycle for UI Component

20170519025016_img20170519-11-107pbac_720

  • Development Lifecycle for non-UI, especially unit level, Component

20170519025038_img20170519-17-1lny2qd_480

  • Robolectric

20170519030006_img20170519-14-1lgebza_720

  • Espresso’s lifecycle

20170519031440_img20170519-17-wz5rvd_480

  • Boundaries between M level and L level

20170519031901_img20170519-17-hireh1_720

Previously, I’ve published blog for test strategy for mobile.
This video is similar to the article 🙂

ICST2017メモ

ICST2017に参加して、会社のBlogには以下の通り少し書いたのだけれどGistに残したメモをGistのままにしておくのはもったいなかったのでメモがてら。

techlife.cookpad.com/entry/2017/04/04/180000

[design]inclusive design(My 4th day)

This post is memos for 30 days of accessibility testing.

https://dojo.ministryoftesting.com/lessons/30-days-of-accessibility-testing

4th day’s mission is researching inclusive design. So, I attach some articles in this post.

[Swift]try!Swiftで学んだことまとめ

私は職場で作ってきたテストの話のうち、UI Testに近いところの話をしました。

英語での発表は初めてだったのですが、一部想定通りに話せなかったところがありながらも無事に終えることができ、ホットしました。日本以外から来た人含め、いろんな人から英語も聞き取りやすかったし内容も良かったと言って貰えて、ひとまず安心しました。

お題の悩み

私はSwiftを使ったテストの話(Unit Test)をするかとか、protocolベースのDIの話をテストに絡めるか、UI Testの話をするか悩んでいました。

推薦されたことで話すことができるようになったので、try!Swift全体の中でそれぞれの話す内容が重ならない程度の話題にした方がバリエーション豊かになって良いかなと思い、UI Testsやその周辺の話をしました。

ただ、このレイヤの話はSwift自体でそこの話をするにはネタがない。XCUITestとかだとSwiftではなくiOSフレームワークの話になりますしね。半端にSwift x XCUITest(内部コードとか)の話をするよりは、テスト全体とUI Tests、Re-Engineeringnの話をする方が独自性を持った話ができるかと思い、結果的には話すことにしました。

結果的には、unit test関係で想定していたセッションの内容は他のスピーカーの方々が行なっていたので、重ならずに良かったかもしれません。

運営の方からは良かったとフィードバックをいただけたので、推薦いただいたことに対しては役目を果たせたと感じてはいます。

他のセッション

すでに nowsprinting さんがまとめを書いていたので、テストに関してはそこにお任せ。
http://nowsprinting.hatenablog.com/entry/2017/03/05/061441

内容自体はprotocolやstruct付近を使った話で、functional programmingもかじっていると理解を深めることができる内容でした。

The Two Sides of Writing Testable Code

ここで出てきた “co-effect” に関しては以下が参考になるらしいので、少し読んでみようと思います。

ReactNative

3日目のハッカソンでは、その間に行われたReactNativeのゲリラワークショップを経験しました。

ReactNativeのテストには、JSレベルでは jest、UIレベルだと testID を付与してからのUI Test系ですね。
JSの世界でテストが実行できると、unit testでもXCTestよりも素早くテストのサイクルを回すことができて良いですね。

最後に

本当にお疲れ様でした & ありがとうございました

[Mac][RedwoodHQ]Run on Mac

RedwoodHQ on Macを過去書いた時点ではMacで動かすことができていなかったのですが、最近見て見るとLinux/Mac上でも動作するようになっていました。

http://redwoodhq.com/redwood-download/

からダウンロード・展開して、

$ ./start.sh

を実行、 http://172.0.0.1:3000 へブラウザからアクセスする、です。私はNode 4.7.2で実行していました。

ちなみに、このRedwoodHQは以下にフォークされてPRなどが取り込まれていました。

https://github.com/wolterskluwer-redwoodhq/RedwoodHQ

もともと作ってた人は退いたのかな。