[iOS]memo for ios-device-control

Around 5 months ago, Google has opensourced ios-device-control to make iOS related work automate. The repository supports both real devices and simulators.

https://github.com/google/ios-device-control

It provides some examples and [https://github.com/google/ios-device-control/blob/master/java/com/google/iosdevicecontrol/examples/ExampleSimulatorDeviceControl.java] is one example with Simulator. When we run the example, we can see the following outputs.

$ java -jar SimulatorDevice-jar-with-dependencies.jar
Jan 15, 2018 12:15:03 AM com.google.iosdevicecontrol.examples.ExampleSimulatorDeviceControl main
INFO: Screenshot written to: /var/folders/y6/524wp8fx0xj5q1rf6fktjrb00000gn/T/screenshot4392370072269065541.png

Google has EarlGrey for test automation against UI level and this repository doesn’t compete with it since this tool looks mainly for handle real devices, I guess. I know every one who hope to enhance test automation for iOS struggling with the difficulties.

Have a good automation 🙂

Advertisements

[NPM][Appium] Restrict installed module size

I found https://github.com/appium/appium/issues/9912 and I learned the npm‘s --production flag to reduce the module size.

Install without devDependencies

$ npm install --production

https://docs.npmjs.com/cli/install#description

With the –production flag (or when the NODE_ENV environment variable is set to production), npm will not install modules listed in devDependencies.

Remove devDependencies resources

https://docs.npmjs.com/cli/prune

$ npm install
$ cd node_modules/appium
$ npm prune --production

[Appium][Ruby]Run tests in parallel

When we run Appium in parallel on one Machine and one Appium server with Ruby, we have two ways to implement it. (For Android, we don’t need to configure this kind of environment. We must cover this for iOS because of the platform’s limitations.)

One is thread programming and another is process-fork programming. I’ll put examples to run tests with each method in the below.

  • rake run_parallel_t
    • Run tests with thread programming. In this case, each thread shares their data on the memory, classes. It means once our scenario depends on class method, we can’t keep clean test environment.
  • rake run_parallel_p
    • Run tests with process-fork programming. In this case, each process is isolated each other. So, we can keep the hermetic environment in each process.

I think process fork model is good for this time since we don’t need to depend on thread programming when we’d like to run tests in parallel.

2017年に新たに読んだ書籍群を振り返って

毎年、2015年に新たに読んだ書籍群を振り返って2016年に新たに読んだ書籍群を振り返ってをなぞって。

今年くらいからか、LeanPubだったり、PragaticBookshelfといったところから購入する本が増えてきたように思える。β版のうちから気になるものを買っておけば、すこし安くてに入るというのもあるかも。頭でっかちになるつもりはないけれど、いろんな人と話すときにこういう整理された情報源から話を引っ張ってこれるとだいぶ会話が楽なのですよね。海外の人と対話するときの表現とかも学べますし。

そういえば、日本国外の人と活動する頻度が上がってきたことにより、異文化交流などの書籍も読んだりするようになりましたね。また、それに伴って専門性のある言葉に関しては特に、日本語を主に覚えていたものを英語に慣れさせるために英語の記事をあたるとか、そういう類のものも増えてきた気がします。ここ半年くらいは特に。

そういえば、オライリーから無料で配布される電子書籍が情報が整理されていて良い本であるように思える(ここだと、Chaos EngineeringとDesigning Autonomous Teams and Services)のですが、これを無料で配布できるって驚き…

programming language

Swift

Kotlin

Ruby

Elixir

Software Testing

Software Development

Service Development

Other

end

そういえば、ここ最近でElm系書籍を目にし始めたので驚いている。。。(ただ、最近の言語系は書籍よりも公式なWebページが充実しているのでそちらで触れる方が良いですよね)
JavaScriptとPython、OSS活動で必要になってきているのでどこかでガッと学んでおこうかな…
すこし前に読んだWriting Great Specificationsを頭の中整理のためにもう一度読みたいな。多分、必要になるので。

Tasting report portal again

Today, the reportportal pre-4.0 released.

I’ve posted try reportportal before and I thought the tool looks helpful for us. I know of Allure2 which is close to this tool but report portal is a more pluggable reporting tool.

The tool provides to analyze test results using ML technology. We can see the feature’s video from https://www.youtube.com/watch?v=d2ekWI2exZ4 and it looks interesting. I guess the feature will be a handly trial to analysis test resuts.

We can run the tool with docker-composer easily and also, we can add test data via demo data section. Read http://reportportal.io/docs/Project-configuration . Thus, we can see some dashboard to confirm the behaviour.

Also, we can handle data via API and the portal also provide LDAP authentication, but it’s beta yet.

Reporting and management bugs with scenarios help developers and the tool also considers automated test scenarios with some testing framework.

2017年 ~> 2018年に向けて

ちょうどクリスマスが終わったくらいだけれど。

2016年振り返りと2017年へ からはや1年。アラサーといっても、四捨五入が必要な歳になった。

2017年

昨年のやりたいことに書いていたSwift/Kotlin、海外との関わり付近は仕事の兼ね合いもあって前進中。そこに加えて、OSS関連は良い方向に向かっているようで良い年でした。私の専門性の源泉はテスト/品質よりなので、そこは今後も大きく離れないようにしたいなーという感じを持っています。

完全なプライベートはここでは書きませんが、全体としては楽しく/幸せな感じで進んでいるのでよかった。

会社関係

  • 海外事業部にうつり、日本国外を対象としたサービスの開発にどっぷりになった
    • UKのBristolに国外アプリの開発拠点があり、開発メンバの大半はそこか日本オフィスにいるリモートな環境
    • 役回りはテスト/品質系エンジニアを継続して行っており、海外チームの中でもその手の役割を創っていく側になりました
      • 類似の専門性を持った人がいない + 完全英語環境 もあって、やっぱり今までの経験を色々と手順を追って噛み砕きながら進める必要があり、挑戦的
  • 英語を主とした開発にうつり、主言語として英語、もしくは第二外国語として英語、という形のコミュニケーションが増えた
    • 異動当初は色々ともたついていましたが、最近はだいぶ全般的に改善できたと思う…
    • 私の役回りとして必要とされる英語スキルにはまだまだ達していないので、特に表現周りや落ち着いて話して伝えるところを継続して訓練していこう

OSS周り

  • 昨年にAppiumのコアメンバに入り、そこからRubyだけではなくPythonクライアントをみたり、Appium自体へのコミットも増えた
    • JavaScriptはそこまでがっつり触ったことはなかったので、NodeJS環境におけるJSを学びながら…という状態
  • Appium初期から開発されていたこともあり歴史的な複雑さも持ったruby_libをコアパートであるruby_lib_coreに分離して、最小限の機能を持ったところと分離させた。これのおかげでか、W3C対応とかも見通しが良い感じでクライアントの実装を修正できている。
  • こういったElectronアプリをちょっと創ったりして、面倒なところを減らせるようにもした
  • OSS周りでは、知らない人からこういうOSSつくったんだよね、とか、Appium関連からちょっと先進的な取り組みのお誘いをもらったりするようになった
  • ほか、細かなものはちょくちょく創ったりしていたかも
  • そういえば、profileを作成するサービスあったのでやってみた

 

そのほかの活動

  • try!Swift 2017で話した
    • この頃から、英語の発表の機会がちょっとできた
  • ICSTへの参加や、ICSTの非公式meetupを開いてGooglerのかたとも直接色々お話できた link
  • Selenium Committer Dayで話した
  • 海外のテスト/品質系カンファレンスにCfPだした
    • 今2つ出して、1つダメだった…

そのほか

  • 海外からもユーザ企業から直接的なオファーが届くようになった + 複数回の技術的なやりとり含んだ英語の面接もパスしたし良い経験がもてた
    • LinkedInだったら今までももらっていたけれど、そうではない経路も出てきたのはびっくり
  • Web記事を少し書いた link
    • これからも少し書く予定

2018年

やりきること

  • CookpadTechConf2018でちゃんと話きる
  • 仕事で私と同様以上の専門性を持つ人を招き入れる(英語圏が主な対象ですが、ゴロゴロいそうなので)

やりたいこと

  • (願わくば)数個のテスト/品質系の海外カンファレンスで話す
  • ちょっと考えているやつを形にしていきたいなー
  • 私生活はもちろん大切にしたい

そういえば、ElixirにProperty-based testingが標準ライブラリとして組み込まれる予定であるというところ、個人的にはオーという感じだった。標準という位置付けが強いですね。社外アプリでもElixirを使う未来、くるかなー。

http://elixir-lang.github.io/blog/2017/10/31/stream-data-property-based-testing-and-data-generation-for-elixir/

[Appium][Android]Scrolling to an element

Just for my memo

When we scroll views using Appium, then we have two ways to achieve it.

  1. Use UiScrollable

The below method is implemented in Ruby client.

  1. Use TouchAction or related actions.

The below is methods I used to implement as helper methods in my framework.

In my experience, 2 is almost stable than 1 since 1‘s behaviour depends on OS side and it also depends on devices,(and OSs).

“Designing Autonomous Teams and Services”を読んだ

元々はこれ => http://www.oreilly.com/programming/free/designing-autonomous-teams-and-services.csp

ちょくちょくと、オライリーさんからこういった無料で購読できる、ちゃんとした内容のものが増えているように見えますね。こういうところで経験をまとめ、今後のビジネスにしていくという著者のスタイルとか一般化しているのでしょうか…

この書籍を表現すると、複雑な課題に自律的に取り組める組織/サービスを作る、ということだろうか。(タイトルのまんま…)

実際に、この書籍は単に組織の話だけではなく、例えばBDDやユースケースをモデリングして管理する為のサンプルの提示なんかもしている。Microservice関係の書籍、Spotifyのエンジニアリング組織といったあたりの有名どころの情報に触れていない人にとっては、よくまとまった書籍という感じがします。

気になったところをかいつまんで以下に残しておく。あまり文章としてまとめる気持ちにならなかったので、今後の自分のポインタとして…


  • どこに境界を引くかというところ

To maximize autonomy and enable business agility, it is essential to align organizational and technical boundaries.


  • 誰/何に自律的なところを期待するか
    • これらを持っているチームの場合、より高い嬪度で良い連携を組むことができる。
  • Aligned autonomy—that is, a shared understanding of the company’s strategic context and key objectives
  • Autonomy to make business and product decisions
  • Autonomy to develop a rich understanding of user needs through continuous discovery directly with customers
  • Autonomy to employ technical practices that enable continuous delivery
  • Autonomy to organize technical and team boundaries around business outcomes

リーダーシップ

Leadership requires two things: a vision of the world that does not yet exist and the ability to create it.
Simon Sinek


OKRの設定とその達成への取り組み


より効率的な、高い成果を出すのであれば、横断的、協力的、誠実にこなしていくことが必要となってくる。

If high performance is your goal, you need to accept that the design of teams and the design of software systems are inextricable. You must design cross-functionally, collaboratively, and conscientiously.


ユースケースのモデリングの話。以下のようにユースケースをモデリングし、管理していく。読んでると、Specification by Exampleのような話が展開されていることがわかる。

When I want to so I can .

そのほかに、TDD/BDDやコンテキストマップなどの使い方も提示している。使い方のきっかけを載せている感じ。


チーム間で知識を共有していくことで、各々のチームの発展にも言及していた。

  • Show and Tell
  • Cross-team pairing
  • Cross-skill pairing
  • Mapping the System

だいたいは想像している感じ。これらを組み合わせて、知識を循環させるという感じの内容。


そういえば、Complexityの理論と整理も行われていた。Simpleが一番因果関係が予測可能な状態を表現する。だんだんと、不確実性や複雑さがまし、予測だったり区別がはっきりしなくなる。これらに対してどのように対応していくか、対応できるようなチーム/組織にしていくかというのも一種の目的とその設計となってくるのだろうな。

  • Simple
  • Complicated
  • Complex
  • Chaotic
  • Disorder

ところで、これは、科学よりもアートに近い、と表現している箇所がある。確かに、組織論は科学的なものよりも、どう設計して表現させていくか、というところに寄っていくのでそう表現しているのだろうな。


[Appium]See the screenshots and source on offline after tests failing

Almost software engineers take a bunch of time to investigate the cause when automated tests fail.
And they try to make sure whether the error is test code itself or product code. In the case, helpful error messages and additional information help us so much and save time for the investigation.

In this article, I explain some tips to make such investigation comfortable and show you a helpful app for it.

The repository is: https://github.com/KazuCocoa/appium-source-viewer

What kind of data do you get when tests fail?

Almost case, guys, use GUI testing tools like Appium, get screenshots when tests fail. Also. Some guys get videos as an additional information as well. They’ve become common in the mobile testing world recently.

By the way, can you find the way to fix the fail only from the screenshots or videos?

If your automated test code uses displayed words to find elements or some actions, you probably fix the test code from them. But, using resource-id for Android and accessibility identifier for iOS are common recently, and they can’t find from screenshots or videos because they are embedded in code level. Not for humans. In this case, you must find elements in code level and you also must run again to make sure the test code fixed.

The time is sometimes dull and wast. Also, we must repeat launching the test app and go to the target view to see view hierarchy by uiautomatorviewer, for example. The activity takes a bunch of time.

Thus, if we can get the hierarchy and view at the same time and we can see them easily in the investigation, the time will be short.

Get the source

To achieve it, I strongly recommend you to get page_source as well as screenshots when tests fail.

The page_source looks like:

<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>

Espresso or EarlGrey get such results and show us as their results. So, we can understand why the tests failed and which elements should we get or something… (XCUITest can’t get such information, I think…)

Screenshot x Source

Only getting source is a bit difficult to image and understand the target view from it since it is just XML.

To reduce such difficulty, we can use visualisation tools like Appium-Desktop.

Offline x Screenshot x Source

Appium Desktop is so helpful to see elements mapping to the view. But the tool requires network connection between Appium server and test targets.

So, I developed a tool which can map a screenshot and its source, and visualise us like Appium Desktop. We can see some highlights in the screenshot and the source equivalent each other.

sample

The repository again: https://github.com/KazuCocoa/appium-source-viewer

The tool will help us to find the cause and how we can fix it only for failed test data, the screenshot and its source information.

I’ve put the usage in the README, but you can use the app following:

  1. Download the binary from release
  2. Unzip and copy the app in Application
  3. Set a screenshot path and a source path
  4. Reload from reload icon

I’ve checked only on macOS, but it’s Electron-based application. So, I guess it can work on windows, too.

Conclusion

I put some tips to make fix failed test easy and the app to help it.

Have a good testing!

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系列でも動くものをビルドすることはできるでしょう。(どなたか…)

最後に

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