Category Archives: test automation

A couple of days ago, I had a conversation about Android tests on Twitter. I would leave it here a note. The conversation was: How to run UI tests in order Is there any good way to make them stable? How to get a system dialogue via Espresso? We discussed: It’s better to use RuleChain…More

[Appium][Flutter]Espresso driver x Flutter

I have updated my sandbox repository for Flutter x Appium. Update test app based on Flutter 1.0 Update test scenarios for it In Android, I could launch and through a simple scenario with UIA2 driver. But I could not succeed to launch it with Espresso driver. Below log is here Something happened with instrumentation combination……More

Read “Property-Based Testing with PropEr, Erlang, and Elixir”

I finished reading “Property-Based Testing with PropEr, Erlang, and Elixir” a couple of days ago. Do you know or know of the testing? Property-based testing is very interesting to learn. Through this book Through this book, we can learn what is property-based testing, how to consider property driven and practice in a real-world product. If…More

[Appium][Espresso]Using View Tag to test for Android on RN

I investigated before about testID feature if ReactNative [ReactNative][Appium]testIDの振られ方. Then, I found the framework maps the testID as android view tag. link The view tag is available via Espresso framework. Appium had not accessed the element by uiautomator2-driver since it uses uiautomator framework. But, appium-espresso-driver has been published. The driver can access to Espresso framework.…More

[Appium]appium-doctorをつかて環境の確認を行う

Selenium/Appium Advent Calendar 2018の19日目の記事です。空いてたので、またちょっとしたtipsを載せようと思います。 今日はAppiumには環境構築時に設定を確認できる appium-doctor と呼ばれるコマンドラインツールを紹介します。何かのOSSなりのツールを利用する際、最近はよく xxxx-doctor と呼ばれる環境確認用のコマンドラインツールをよく見かけるかと思います。Appiumも前々から同様なdoctorツールを持っていました。 v1.6まではこの appium-doctor は必須環境のみを確認するツールでした。例えばAppium自体の実行環境、AndroidやiOSに対してAppiumを実行できる環境を確認することができていました。あと、問題があった時に可能な限り自動でfixさせるautofixの機能もありました。 v1.7以降ではオプションとして利用される他のツール群の確認もするようにしました。 現在のmasterでは以下の通りの結果を得ることができます。v1.7以降にも少し確認する内容を増やしたり文言を調整したので、少し現状の npm install -g appium-doctor で入手できるものとは異なる表示、結果かもしれません。 この拡張により、画像による要素検索を行うために必要な opencv4nodejs が入っているか、などが確認可能です。iOS Simulator限定ですが、あらかじめ各種permissionを操作するためにplistを直接操作するAppleSimulatorUtilsも利用可能になります。いくつかのpermission操作はもとからサポートしていたのですが、これにより、より多くの種類のpermissionを調整可能です。 私は以前、このutilsを使いテスト実行時に不要なpermission dialogを抑制するためにあらかじめ権限を許可しておく、などしていました。（毎回、xxxのダイアログが表示されていると閉じるというようなXCTestでも必要になる記述を、Simulatorだけですが省くことができます。） Android/iOS/オプションの設定の中には手動で設定する必要のあるものもいくつかあります。そのためautofixにより全て自動で設定、とまではいかないのですが、手探りで必要なライブラリを手に入れていったり、何かライブラリのインストールが必要になる(例えば opencv4nodejs など)エラーに出くわして初めてその対応をする、というようなことを減らすことができるものとなります。 あまり大きな機能ではないですが、初めの一歩であったり、環境確認の時に利用していただけると幸いです。More

[Appium][Android]Set DataPicker and TimePicker via Espresso Driver (Eng)

This post is English edition of [Appium][Android]Set DataPicker and TimePicker via Espresso Driver which is for Selenium/Appium Advent Calendar 2018 in Japanese. mobile command Appium provides mobile command to conduct native commands in order to extend Appium actions using native features. In general, we follow the W3C webdriver spec. We add new endpoints which have…More

[Appium][Android]Set DataPicker and TimePicker via Espresso Driver

Selenium/Appium Advent Calendar 2018、17日目の記事です。空いていたので、ちょっとしたtipsということでAppiumの mobile command を紹介しようと思います。(English edition is available in [Appium][Android]Set DataPicker and TimePicker via Espresso Driver (Eng)) AppiumはW3Cに沿った基本的なコマンドのほか、iOS/Androidなどに特化したコマンドを拡張しやすくするために mobile command を定義しています。これは、例えばW3Cの定義には当てはまらない上に、AndroidやiOS固有の機能を拡張するためによく使っています。 従来の機能追加の方法としては、各種コマンドは全て何らかのURIにマッピングされていました。 ただ、特定のDriverでしか使うことはないのに必要以上にURIを乱立させたくはありません。保守が難しくなってきます。 そのため、 mobile: というprefixをつけたコマンドを文字列で定義し、このように各々の固有な機能を定義するようにしました。Androidだと adb コマンド、iOSだと siri の機能を使ったコマンドなどが拡張されています。 ここでは、それらで定義されたAndroidの2つのコマンドを紹介しようと思います。 DatePickerとTimePicker 最近ではAndroidだとDatePicker, TimePicker, 任意のpublic method を呼び出すことができる backdoor などの機能が追加されました。 これらの機能は、Appium 1.10.0 などで automationName: espressoと指定すると利用可能な、 Espresso Driver に追加されたmobile commandです。技術的にはEspressoベースだからできるようになったことです。 これらは今まではuiautmaotor経由だったためにできなかった/不安定だったところを解消する可能性が高いです。 テストコード 先ほど埋め込んでいたanimation gifは、すでにruby_lib_coreに用意している以下のテストコードを動かしている時のものです。実際に mobile: setDate…More

[Flutter]Tests strategy in Flutter

I read the documentation of Flutter 1.0 based. I also tried to run each test type explained by the documentation. Flutter has three type testing feature. When I saw the page and below a table, I remember my opinion for mobile test automation like 1 or 2. The flutter also has a similar role for each…More

[Swift]WebDriver clientライブラリを作ってみる

Selenium/Appium Advent Calendar 2018、7日目の記事です。 Selenium/Appiumを使っている皆さんはWebDriverの W3C仕様 を見聞きしたことがあるかと思います。このW3C仕様に沿ったクライアントライブラリを使用することで、この仕様をサポートするサーバに対して同じ操作を発行、実行させることができます。そのため、必要であれば自分たちの開発言語を用い、必要な仕様だけ満足するカスタムクライアントを実装する、といったことも容易になります。 モバイルには限らないのですが、テスト自動化などの文脈でテストツールを選ぶ際、この どの言語のWebDriverクライアントを使うか はよく議題に上がると思います。実際に開発に用いている言語を使うとメンテできる人も増えるし、選べるなら選びたいところですね。 ただ、公式にメンテされている言語、されていない言語と様々ありますね。 モバイル・Appiumの文脈において Appiumを使って自動化を行う際、JavaScript/Java/Python/Ruby/.NETのクライアントがちょくちょく使われるようです。 JavaScriptはAppium自体がNodeJSを基盤として開発であることや、ReactNativeを使ったことのある人にとって馴染みやすいようです。エンタープライズ向けの利用も含めてJavaも多いですね。ちらほらとPython、Rubyも見ます。iOSだと、FastlaneなどのツールもRuby実装なのでRubyをプロジェクトに入れることに対して比較的抵抗は低いみたいです。Pythonは機械学習を絡めたりする場合は特に、とても使い勝手が良いみたいです。.NET を使ってる人は、Xamarinとかなのかな、と推測します。 JavaとSwift Androidの主な開発言語は(Android)JavaとKotlinです。Appium projectがJavaクライアントをメンテしていることもあり、Androidに対してJavaクライアントを選ぶことは普通な選択肢の1つのようです。Javaは周辺のテストツールの既存資産も多いので、テスト集計やSeleniumを使ったWeb側との連携もある程度既存の道を走ることができる点も良いですね。 iOSはSwiftですが、これ向けの主なメンテされているライブラリはありません。一応 selenium-swift はありますが、これは4年間継続してメンテされてはいないようです。元のObjective-C版のSwiftラッパーという位置付けです。このライブラリコードをのぞいてみましたが、大体は class で定義(状態をそもそも持たないのでstructで書いたりできる箇所も含めて)していたりと、書き方など含めてよくできるかなーという感じのものでした。 そのため、W3C仕様の把握も含めて実験的にSwiftをベースにクライアントを書いてみました。まだ構造として変えたいところもあるので、本当に実験的なものです。その時の、どういう感じでWebDriverクライアントを作ることができるか、という感覚を今回は共有しようと思います。 以下は AppiumSwiftClient#8182d8f4時点のものをベースに話をしています。セッションを確立し、その要素に対してタップするなどの操作を実現するためのコードは以下な感じです。(AppiumFuncTests) WebDriverにおけるクライアント/サーバ間のやり取りはJSON形式です。そのため、SwiftではCodableを中心に使っています。これは色々と説明しているWebサイトも多いので、Codableを使ってJSONのマッピングに関しては特に言及しません。エラー処理も良くしては行きたいですね。 実装 以下ではSwiftのコードを書いていきます。どんな感じでクライアントライブラリを書いていったのかを載せていこうと思います。 外部ライブラリに対しては特別な依存関係は持たせていません。テストコードで利用しているものはありますが、ライブラリの中ではありません。似た簡単な処理が続くので、簡易的な処理だけであれば多分使う必要は無いかな、という感覚ではいます。 https://github.com/KazuCocoa/AppiumSwiftClient Create Session まずは入り口 Spec https://www.w3.org/TR/webdriver1/#new-session command HTTP method POST URI /session Request body クライアントがサーバに対して送るJSONは以下なフォーマットです。実際はalwaysMatchesもあるのですが、それは空でも問題は無い(現状のSeleniumクライアントライブラリのいくつかはそもそも送ってない)のでここでも省略します。 Response body それに対して、例えば以下のような結果が得られます。 この応答はW3Cのスペックに沿ったものです。 Implementation code:CreateSession.swift エラー処理は除いています。ここで session id を得られたら、通常はサーバとのセッションが確立しています。いったんの目的は達成。…More