Tips for UI/Scenario Tests: Recording screens and getting view hierarchy

When we run UI related tests, debugging failing test is one of the most difficult and need a bunch of time task. To make it easier, we usually take screenshot, capture videos and make error report helpful.

Taking screenshot is very famous, and I skip it.

Recording

Android

Android provide screenrecord command to record a video for Android 4.4+.
I’ve implemented a bit helpful library, named droid_adbs

In the library, you can record video like the following. record.start call the screenrecord command in forked process. So, you can also start recording in setup and finish it in teardown.

require 'test_helper'

class DroidAdbsCommonsRecordTest < Minitest::Test
  def test_record
    record = ::DroidAdbs::ScreenRecord::Recording.new
    record.start

    sleep 10

    record.stop

    # Should wait to finish exporting recorded file
    sleep 1

    record.pull
    assert File.exist? "./droid_adbs_video.mp4"

    record.delete
    File.delete "./droid_adbs_video.mp4"
  end
end

iOS

For Simulator, we can capture video easily with the following method.

xcrun simctl io booted recordVideo capture.mov

Tips

More or less, recording video increases devices/machines load. So, I recommend recording screens only you need. For example, once run your test suite and retry failed tests with enable recording the screen then.

Capture view hierarchy when test failed

With ruby_lib and Appium x RSpec

RSpec.configure do |c|
  c.after(:example, type: :feature) do |example|
    if example.exception
      # capture screen
      view_hierarchy = source # source is getting view hierarchy command
      # Save view_hierarchy in particular files.
    end
  end
end

Espresso

  • We can get hint to finding elements.

EarlGrey

  • We can see view hierarchy by default.

XCUITest

  • I’m not sure we can get such information from error result.

Conclusion

Helpful error results decrease a bunch of time to debug and detect the cause.

Advertisements

try reportportal

I tried reportportal to research awesome extensible reporting system. The framework provided by Docker and it’s very easy to try demo app via docker-composer

I know of Allure2 and it also awesome.

The following is a capture image.

「Building Evolutionary Architectures」を読んだ

Building Evolutionary Architectures: Support Constant Changeを読みました。

“Evolutionary”というものをどう表現しているのか、そのケーススタディを知ってみたいと思ったからです。

Evolutionaryとは、小さく変更をくわえながら、フィードバックループを回し、どのようにシステムを開発していくかを学ぶというところをいっているようです。その要素としてCI/CDの環境を作っていたり、例えばMicroservicesなどの話が出たり、チーム構成の話にも及んでいるところがあり、なかなか面白いものでした。チームの話だと、そういえば”Culture”という言葉も度々出てきたので、そういう環境づくり含めた全体の、文字通り”システム”(複雑系)を対象として設計するというものという印象を持ちました。

Fitness Functionと表現している、拡張していくような機能を対象に、その機能を壊さずに変化させていくか、というところでどのようなプラクティスがあるかとか書かれていました。そのように変化させていくことを”incremental change”というような表現を使ってたりします。Microservicesの文脈で度々目にするConsumer-Drivern Contractsの話も出ていました。この書籍を読んでいると、様々な小さなチームの責任範囲が重なる(もしくは重ならない)、システムの境目となるところを横断的な、例えば横断組織としてのテストチームがケアする、などにも言及していて、Consumer-Drivern Contractsが単なるツールの話ではなく、むしろそういう境目に対する話に絞っていたのはよかったです。(Pactガーというような言葉だけで終わらなかった)
もちろん、そういうテスト/品質をみる人は各々の責任領域ベースでのチームにいたりしてるけれど、横断的な人の役割などを別途明言しているところがよかったですね。

Re-engineering Legacy Softwareなど読んでいると、色々なところで話が重なっているところが見えたりするかと思います。また、Servive Oriented ArchitecturesやEvent Driven Architectures、Service Based Architectures、Serverless Architecturesなどのツール側の設計の話もありました。これらの説明、システム間の関係、要素技術などを整理してたりします。ある程度知ってる人には良い要点整理になるかと思います。

Amazonの有名な2枚のビザの話もコラムにありました。

Each team is cross-functional, and they also embrace the philosophy of “you build it, you run it,” meaning each team has complete ownership of their service, including operationalizing it.

ということをいっていて、それを最適化するような活動までを責任持つことを意味すると書いているところが個人的には好きだった。

そういえば、”Culture of Automation”という言葉も出てきていて、やはりどこまで自動で(短時間で)実行できる環境を作るかは基盤要素なのだなと感じました。

[book]Read Chaos Engineering again

I read the Chaos Engineering again. This book also.

And I chatted a little bit with one of my friends on the Twitter. So, I also put the conversations here.

[Elixir]format syntax automatically

https://github.com/elixir-lang/elixir/pull/6639/files has been merged to master, and Elixir lang support formatting feature by default.

The following library is my experimental place and I’ve adapted the formatter to the library is create a pull-request.
https://github.com/KazuCocoa/http_proxy/pull/43/files

“Humans vs Computers” has educational case studies

I had read Humans vs Computers.

This book has a bunch of stories against bugs, how bugs affect humans, humans how embedded bugs in computers. Various case studies help you understand what happens if developers embedded bugs into the real-world computers.

Thus, you can learn them in one book. So, I describe this book as educational I mentioned in this title.

When I read Mr Null’s story, I tweeted the following. Mr Null means the “null” is a part of human’s name. And I remember the one of my friend who has “sudo” in his name. As you know, “sudo” is the command to be a superuser in the computer world.

Also, the following tweet attracted me because the Tokyo stack’s bug story is a one of famous stories in test/quality world in Japan.

Anyway, you can learn and know how many bugs are embedded in computers and how they affect humans.

[Swift] Identify not XCTest against XCUITest and EarlGrey

XCTestでは、Swiftの時にAppDelegateを取得しようとするとクラッシュする問題があります。
そのために、

XCTAssert(NSClassFromString("XCTest") != nil)
XCTAssert(NSClassFromString("XCTestCase") != nil)
XCTAssert(ProcessInfo.processInfo.environment["XCTestConfigurationFilePath"] != nil)

などを使い、XCTestである場合はmockしたAppDelegateを使うなどの対策を行うことがあります。ただ、この場合だと、 XCUITestEarlGrey によるテストを行うときもこの判定に引っかかります。

以下の差分には、XCUITestとEarlGreyに置ける上記判定を入れています。両方とも同様に判定が行われます。

https://github.com/KazuCocoa/test.examples/commit/cd3ec48b741320071471b27b3ad6254ce4fbacd5

これを避けるために、例えば環境変数でEarlGreyであることを指定する、などが必要。

XCTAssert(ProcessInfo.processInfo.environment["EarlGrey"] == "true")

https://github.com/KazuCocoa/test.examples/commit/aa527223208d4d56260fa0111ccf158554c0d12f

プロセスに対する環境変数、iOSのテストだとちょくちょくお世話になることがあると思うので、覚えておくと良さそう。xcodebuildなどに対して環境変数を与えると同じようなことになりますが、これはプロセスに対する環境変数なので注意が必要(プロセス外で定義した環境変数は参照されない)

[Elixir]read “Craft GraphQL APIs in Elixir with Absinthe”

Craft GraphQL APIs in Elixir with Absintheを読んだ。Amazonからはこちらから購入可能になる予定らしい。

Beta配信されて購入できるようになったので、GraphQLを学ぶことも含めて購入、読み進めてみた。GraphQLは、ざっと情報を巷のBlogなどで見ているが、実際にサンプルアプリ以外でコードを書いてWebアプリを開発したことはない状態。

はじめにGraphQLの簡単な話があったのち、ElixirのAbsintheを題材にしてGraphQLを実際に作り、実装してみるという流れ。これにより、GraphQLのクエリの形や仕様を学びながら、実際のツールの使い方を学ぶことができる。この書籍を書いているBruce Williams氏とBen Wilson氏は実際にGraphQLを使いプロダクションの開発を行なっているらしく、その知見も少し味わうことができる。

デフォルトではAnsintheはこのブラウザツールが有効になっている状態で開発を行うことができる。一方、プロダクション向けには interface :simple という形式を router.ex などに指定すると良い。なお、本書ではAnsintheはPhoenixフレームワークを題材として、提供されるサンプルコードもそれを使っているがAnsinthe自体はPlugなど含めて別にPhoenixに限ったフレームワークではない。

GraphQL関係の他には、以下のようにパターンマッチを使うことができると知らず、本書でできるとしったことがよかった。新たな知見 🙂

# define `fn` with some pattern matching
f = fn
  1 -> 1
  2 -> 2
end

# Pattern match
f.(1) # 1
f.(2) # 2

ともあれ、ざっとGraphQLの概要を知りたいとかだけだとこの書籍は不要そう。実際にElixirを使いながら学ぶという形には良い。実際のサンプルコードもあり、そのコードはドキュメントなども豊富なので、コードリーディングの良い題材にもなると思う。

“初めての自動テスト”は様々な人に手にとって読んでほしいものだった

9月21日に発売された”初めての自動テスト ―Webシステムのための自動テスト基礎”を恵贈いただいたことと、少しレビューさせて頂きましたので合わせてこの書籍に関して書こうと思います。(以下、本書)

この本は元々、The Pragmatic Bookshelfでβ販売から開始されたThe Way Of The Web Testerが玉川さんによって翻訳されたものです。この書籍の著者は、アジャイルサムライを書かれたJonathan Rasmussonさん。

私はβ配信の頃にこの書籍を見つけ、過去、このBlogにおいても簡単な感想を書きました。その頃から少し後半が更新、少し内容が追加され、2017年6月29日に最新版が配布されました。本書はその最新版を翻訳したものですので、その内容は最新のThe Way Of The Web Testerと同等のものとなっています!

私は、玉川さんととある活動で知り合っていたこともあり、本書の翻訳レビューと主にはRubyコードに関わるところで相談させていただきました。また、過去にこの書籍の原書を読んで内容の素晴らしさを感じていたので、レビューの相談を頂いたさいも良い意味でとても驚きました。レビュー時から感じていたのですが、この翻訳版である本書の表現などの素晴らしさは玉川さんのご尽力のおかげです。とても良い仕上がりになっているかと思います。

本書に軽く触れる前に、私がこの書籍で好きなところを残しておきます。本書は、開発プロセスなどのテストに関わる周辺環境をなるべく剥がし、テストやそのコードに関わるところの足場に注力しているところです。一方で、ただ単にテストコードの話だけに止めるのではなく、そこに至るまでの話を チーム を中心にしているところが気に入っています。そのため、英語版、日本語版共に、これからテストに入門する人、経験の少ない人、経験の深い人各々に、それぞれの良さをつけてオススメしたいと思っています。

ここで少し話を脱線すると、本書に書かれているレガシーコードに対するUIテストの導入話や、テストピラミッドの話は、少し前にtry!Swiftにてお話させて頂きました内容と同じようなことも言っています。そのため、本書はWebと題しながらも、モバイルなどにも汎用的に使える考え方も多いことを感じるでしょう。

では、少し本書に触れます。

チームの人に

第1章、第8章は概念、実際にテストを導入するときに気にしないといけないところを中心に書いています。そのため、広くチーム全員にオススメします。この箇所で共通認識を持っていると、導入するテストの全体像に対する共通認識を説得する手間が省けるとおもます。読書会みたいな感じで話し合うのも良いかもしれません。また、ここではプロダクトに対するテストの全体像、どんなテストを、どのくらいの量、自動化すると有用かということを知るもとができます。

コード書く経験があまりない人に/手動テストが主な人に

8章までは基礎的なことが書かれているため、そこでテストコードの実装含め、基礎を学ぶことができます。実際にコード書きながら様々なユニットテストを学んだり、Webアプリの仕組みを大まかに学ぶことがでるためです。ここを学ぶと、発展的な内容を学ぶ土台となる知識が得られ、プログラミングが関わるような勉強会でもある程度話が想像できるようになると思います。

9章以降ではもう少しちゃんとプログラミングに触れたり、より良いテストコードの書き方、テストファーストの考え方まで学ぶことができます。本書にも書いてますが、本書をざっと学び、コードを書きながら経験を積んだ後には、よりテストコードを書き、よりコードを書く経験を増やし、他の書籍などを読みながら自分の力で自動テスト関係やその周辺環境の経験を増やしていけるでしょう。

本書を読み終えたら

プログラミング言語でいうとここではRubyを題材にしていますが、モバイルに足を踏み入れるとJavaやKotlin、Objective-CやSwiftに触れる必要が出てくるでしょう。また、Webでも他の言語を学ぶことができます。言語におけるテストコードの文化や書きやすさの違い、プラットフォームによるテストし易さの違いを学びながら、より発展的なエンジニアとしての道を歩むことができるでしょう。

よりテスト技術に関して学びたい場合は、テスト技法関連の書籍を追ったり、GitHubなど含めてモックライブラリなどのライブラリを追うと良いでしょう。様々な、それぞれ使用感の異なる多様なライブラリに出会い、それぞれの良し悪しを学んだりできるかと思います。

また、ここの学んだことをベースに、アジャイルテスターのような方面に足を踏み入れることも挑戦的で面白いかと思います。開発プロセスなどが絡む方面に進むこともまた面白いかもしれません。

いずれにせよ、本書は様々な経験をする足場を学ぶことができるので、ぜひ手を取ってみていただければと思います。

read “Learn Functional Programming with Elixir”

少し気になっていたLearn Functional Programming with Elixirがβ公開されたので、気になって読んでみた。

内容自体はすでになんらかのElixir本を学んでいると特に目新しいものにはでくわさないと思う内容だった。ただ、7、8章の Design Your Elixir Applications, Handle Impure Functions はまだ公開されていないが、この箇所は少し雰囲気がElixirの説明から実際のアプリケーションに話が寄っている感じがしている。

内容として、高級関数の他に、末尾最適化の話も触れていたし、そこは実際のプロセスモニタリングしながらmemory消費の優位性を明記していたところが良かった。

あとはeager/lazy関数のことも言及していて、以下のような無名関数を使い、lazyな関数宣言を適切にモジュール内で使っていたリファクタリングの話なんかは、少し新鮮で面白かった。

a = fn x -> IO.puts x end
a.(1) # 1, :ok

あと、 :ok, :error で結果を出し分ける言語文化(from Erlang)の話も触れていたり、コラムもほどほどに詳しいところに踏み込んでいて良かった。

最初の一冊よりは、少しチュートリアルをやった後にElixirらしい記述をするためのとっかかりとして学ぶとか、そういう書籍っぽい。