Category Archives: development

[Android][Appium] Page Source of Jetpack Compose

Google announced Jetpack Compose to simplify and programable UI development. I thought it was like Flutter then 🙂 I wondered if we can get view hierarchy correctly via the feature since if the feature is like Flutter, it is not on full Android view system. Espresso and UiAutomator probably cannot find element provided by it.…More

[iOS]Xcode returns an authorization error

When I ran xcodebuild commands, I got an error which was about Install Failed: Error Domain=DVTDownloadableErrors Code=3 “The authorization was denied since no user interaction was possible.” UserInfo={AuthorizationErrorCode=-60007, NSLocalizedDescription=The authorization was denied since no user interaction was possible.} Then, xcodebuild -checkFirstLaunchStatus returns 69 status code. Maybe, it can fix with xcodebuild -runFirstLaunch, but I haven’t…More

[Appium]Re-use existing WDA in create session command

In [Appium] Prevent building WDA with useXctestrunFile or usePrebuiltWDA, I explained how to skip re-building WDA every session in order to make test setup faster. I would like to show a “cache” feature for WDA in Appium. After this PR , the function will work correctly. The PR will be in 1.12.1 or 1.13.0. As…More

[JS]debug using Chrome Dev Tools via VSCode

Chrome provides brilliant toolchain to develop JavaScript, Chrome Dev Tools. I usually connect to the debug console via inspect you can open it on the browser. Meanwhile, the inspector is kind of heavy when you would like to open only console debug interface. I started using the inspector via VSCode. I could open an arbitrary…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

[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

[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