[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

Read “Python Testing with pytest”

Read Python Testing with pytest: Simple, Rapid, Effective, and Scalable to learn Python and testing framework for it. I am new for Python, but I need to maintain some python libraries in order to keep it up to date. Thus, I started learning Python and its world. Thus, I took the Python testing book. Below is…More

[Appium][Python]pytest-xdistを使ってparallel-testsを実現する

Selenium/Appium Advent Calendar 2018、4日目の記事です。 1 日目の 2018 年の Selenium と Appium について、なるべく他の人とかぶらないことに言及するテスト でも言及いただいたのですが、ちょうどこの 12 月より HeadSpin にて活動をはじめました。現状はまだ日本に滞在しています。 今、私は Appium project をメンテしています。その中で感じたここ最近の 普通 になったなということに並列実行(parallel execution)があります。 Appium の公式ドキュメントでも parallel-tests にある通り、その実行方法に関して言及しています。人によっては Selenium Grid を介していたりもします。その中で大事なものは、Appium の各種 Driver と通信できるように、ポートの設定とテスト端末の特定を適切に行うことです。 Appiumの基本構成としては、各種clientライブラリがAppiumサーバと通信します。その先は、Appiumサーバが各種Driver(例えばappium-xcuitest-driver)を経由して端末にインストールされたサーバ(例えばWebDriverAgent)と通信してOS提供のAPIを利用して操作を模倣します。そのため、それぞれの間で行われる通信が正しく行われる必要があります。 https://github.com/appium/ruby_lib_core#run-tests では、 parallel_tests を利用した parallelisation を例の 1 つとして実行可能にしています。 https://github.com/appium/ruby_lib#run-tests-in-parallel ではいくつかの parallelisation を載せています。例えば、Thread を使ったものや Process を使ったものを。 ここでは、Ruby ではなく、Python を使った例を載せておこうと思います。Appium の parallelisation…More

Read “Practical Object-Oriented Design in Ruby” 2nd edition

Finished to read and practiced Practical Object-Oriented Design in Ruby 2nd . The book was 2nd version which has been published 1sr, Sep 2018. The book addresses Ruby mainly in code level, but we can learn OOP styled programming, thinking from the book for non-Ruby engineers. My ordinal motivation was learning programming languages, especially OOP, in English, again. I’ve…More

Read “経時的に変化する製品の品質”

When I cleaned my room, I found 経時的に変化する製品の品質 which was a thesis discussed Quality. It debated Quality changes following time. Quality can categorise synchronic quality and diachronic quality. The difference is time. Synchronic is concerned with something, especially a language, as it exists at one point in time according to a dictionary. While diachronic is concerned with the way in which something, especially language, has…More

“マイクロソフト 再始動する最強企業”を読んだ

数ヶ月前なのですが、マイクロソフト 再始動する最強企業 を読みました。 読んだ背景には色々とあるのですが、書いている内容が私の知っている最近の感じのものと同じ感じで良いものだったのでここに載せておこうと思いました。 GitHubのことなど、だいぶ新しいことも載っており、日本語として今のMicrosoftを読むには良い本かなと。More

[Android]Androidテスト全書は是非手にとって読んでほしい1冊

Androidテスト全書が発売されましたね! とてもめでたい。 私はアーリーアクセスの段階で野次馬のようにいくつかコメントさせていただいたりしました。また、推薦コメントとしてトップにも記載していただいて、大変ありがとうございます。 個人的には、このような書籍が私の学び始めの頃にあればとても知の高速道路を走れたのでは感が満載のものだと感じます。”テスト”という一言で丸っと全体を包むのではなく、いくつかレイヤーも分けつつ分解しているのもとても良いですよね。様々なレイヤーで目的に合わせながらテストの実行環境が整っていく(であろう)これからの市場ですが、それらを利用するにあたり基礎となるものだと感じています。 なおここでいう”テスト”は、一律、開発者テストやテストエンジニアによりテストコードを書いていくという範囲での話に焦点を当てます。 2, 3章 多くは実装やアーキテクチャに依存することも多い話ですね。この書籍では、巷でみる(最近)よく使われるライブラリを使ったテストの書き方のほか、テストタブルの考え方まで踏み込んだ箇所があります。そのため、単なるツールの使い方ではなく、その必要性や用途などまで学ぶことができるのではないでしょうか。それらはAndroidというものに限らないところも多いので、iOSやそのほかのWeb系の話に流れたとしても、転用のきく知識となるかと思います。 ここはコードも多く出るので、読みながら写経しながら進めることが一番良いと感じています。 4, 5, 6章 UIテストのEspresso, Appiumを使った話。 これら、結構比較構造で紹介される場面も見ますね。同じ”UIテスト”という言葉として。ただ、多少はカバーする分野がかぶってますが、私は全く対立するものではないと思っています。(Appium自体、Espresso/uiautomator2を経由して色々とした操作を実現していますし。) そこらへんも説明されたり、具体的な実装の話まで踏み込まれています。 最近だと AppiumのAIによる要素セレクタを試してみたら、自動テストの未来を感じた でも取り上げられましたが、Appiumをモバイルアプリ操作のフレームワークとしてツール群の間に挟むことで、それよりも上のレイヤで様々な取り組みを実施できるなどもあります。これもEspressoだけを中心とした形式で、test.ai のような企業が独立して取り組むには難しい面もありますね。 Espressoの方がとても良い場面も多くあります。そのため、私は Test automation design for Cookpad’s global Android app というブログを、クックパッドの海外事業部のページに投稿しました。そこでは、EspressoもAppiumも(後者は将来的に、ですが)使う流れを載せています。 適材適所で使おう、という話ですね。個人的な日本・世界での活動をベースにすると、両方を行き来できる人は非常に限られていて、そういう人がいる組織は方針の選択など含めてとても強いのだと感じました。私が見た世界の中では、純粋なAndroid開発者だけしかいない(開発者人数も限られている)ところは大体はEspressoですが、Test/QAエンジニアをもつところは大体はAppiumを利用しているようです。その両方を行き来できる人は選択しているぽいです。ただ、Agodaのように色々と判断を倒しているようなところもいくつかあるようですね。 いずれも、Espressoを使うところは単機能(or 1つのView)における実装の確実さを担保していきたいというモチベーションが大きいように思えます。私たちもそんな感じでした。ユーザのシナリオや、実環境に近しいところを対象にしようとしたらAppiumの比率が高くなるという感じでしょう。HeadSpinのように、物理的にもよりユーザに近しいところのテストを世界各国で実施できる環境では、Appiumの方が多数のようです。 7章 JUnit5の話ですね!私もいくつか触ったことがありますが、まだJUnit5を少なくとも10人以上でガシガシ開発しているような組織にはほいそれと導入はできなかったですが。。(JUnit4 のRuleを使ったものもそれなりに持っているプロジェクトですし) JUnit5のいくつかのアノテーションなどは個人的にも導入して行きたいと思っていたものです。なので、JUnit5が成熟して、Androidの標準ライブラリ周辺でも特に壁なく利用できるところまでいくと良いなと思います。 Jetpackとして丸っとした開発ツールの公式化が進みましたし、その中にJUnit5が入り始めるとガッと世界は進みそうだと感じます。 8章 CI/CD環境はモバイルの場合は特に、最近も頭を抱えますね…CircleCIは鉄板だと思います。OSSでしか触れてはないのですが、最近だと性能改善もだいぶ見られるようですね。 私は、1000件程度のnon-UIテスト、40件行かないくらいのEspressoによるUIテストを実装していたプロジェクトにおいて、lint, 全テストをPush毎に、10分以内で全てを終わらせるためにx3 Speed Up Android CI at Cookpadという構成を取っていました。その結果、多くの場合は6分~7分程度で、テストなど含めて開発のフィードバックサイクルを回せるようにしていました。この書籍でいう、”コミットステージ”でEspressoによるUIテストも含めて完了させていた、という感じです。ただ、その環境はAWS上で動作するJenkin環境でした。 それとは別に、将来的には定期的にUIテストの、ユーザ受け入れレベルのものを実施したいとも思っていました。(が、そこらへんは環境の成熟など含めてまだ手軽ではないですね。。。)これにより、手動テストステージの多くは省ける + パフォーマンス系のあたいもここで取得できる状態には持っていけると思います。 先にも書きましたが、これからは用途に応じたテスト実行環境が成熟していく時期だと思うので、読者の皆様は待っておいてもらえると良さそう。(私はそういうところで少しの間、時間を使うことにしました。) 余談 いくつか私も情報の整理のためにAndroid向けの砂場repository とか、iOS向けの砂場repository…More

[iOS][tips]notifyutil to handle notification system

Apple provides notifyutil to handle a notification system. According to their man command, we can see below description there. notifyutil is a command-line utility for interacting with the notify(3) notification system and the notifyd(8) server. It may be used to post notifications, detect and report notifications, and to examine and set the state values associated…More