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

[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. This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an…More

[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…More

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です。 GoogleのEspressoやEarlGreyはテスト失敗時にそのように画面のヒエラルキー情報を出力してくれますね。そのおかげで、修正者は要素がそもそもないのか、ある場合はどのような情報を付与するとそれを特定できるのか、はたまた別な要素である必要があるのかを判断することができます。(XCUITest自体は残念ながら取得できないです(できなかったですよね…?)) スクリーンショット x source sourceだけの場合、そのXML情報を想像できなければ結局は表示内容を確認することになるでしょう。 そこで役立つのがスクリーンショット。ただ、sourceとスクリーンショットを自分の目で照らし合わせることはそれはそれで慣れが必要です。 そんな時、例えばAppium-Desktopのようなツールを利用できたらどうでしょう? 視覚的にスクリーンショットから該当するsourceの要素を確認できる ようになり、だいぶ問題を見つけることが楽になるのではないでしょうか。 オフライン x スクシーンショット x source 便利だろうということで作って見ました。Appium Desktopを参考に、オフラインで使える形にしてみました。 sourceのXMLを読み込み、任意の要素をクリックすると、該当する要素がハイライトされます。逆に、スクショの任意の要素をクリックすると、該当するsourceのXML要素がハイライトされます。 再度、リポジトリはこちら => https://github.com/KazuCocoa/appium-source-viewer これを用いると、 例えばAndroidだと resource-id 、iOSだと…More

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

[Swift] Identify not XCTest against XCUITest and EarlGrey

XCTestでは、Swiftの時にAppDelegateを取得しようとするとクラッシュする問題があります。 そのために、 などを使い、XCTestである場合はmockしたAppDelegateを使うなどの対策を行うことがあります。ただ、この場合だと、 XCUITest や EarlGrey によるテストを行うときもこの判定に引っかかります。 以下の差分には、XCUITestとEarlGreyに置ける上記判定を入れています。両方とも同様に判定が行われます。 https://github.com/KazuCocoa/test.examples/commit/cd3ec48b741320071471b27b3ad6254ce4fbacd5 これを避けるために、例えば環境変数でEarlGreyであることを指定する、などが必要。 https://github.com/KazuCocoa/test.examples/commit/aa527223208d4d56260fa0111ccf158554c0d12f プロセスに対する環境変数、iOSのテストだとちょくちょくお世話になることがあると思うので、覚えておくと良さそう。xcodebuildなどに対して環境変数を与えると同じようなことになりますが、これはプロセスに対する環境変数なので注意が必要(プロセス外で定義した環境変数は参照されない) reference https://stackoverflow.com/questions/26946677/uiapplication-sharedapplication-delegate-as-appdelegate-causes-exc-bad-access?answertab=active#tab-top https://stackoverflow.com/questions/39478895/can-you-pass-environment-variables-into-xcodebuild?rq=1 https://stackoverflow.com/questions/27930137/ios-swift-separate-appdelegate-for-xctest/27981726#27981726More

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

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など含めてモックライブラリなどのライブラリを追うと良いでしょう。様々な、それぞれ使用感の異なる多様なライブラリに出会い、それぞれの良し悪しを学んだりできるかと思います。 また、ここの学んだことをベースに、アジャイルテスターのような方面に足を踏み入れることも挑戦的で面白いかと思います。開発プロセスなどが絡む方面に進むこともまた面白いかもしれません。 いずれにせよ、本書は様々な経験をする足場を学ぶことができるので、ぜひ手を取ってみていただければと思います。More

[Android]Checking Android Testing Support Library 1.0

update: Aug 9, 2017 I encountered no tests found error when running tests with AssertJ and AndroidJUnitRunner1.0.0. https://stackoverflow.com/questions/45402645/instrumented-tests-failure-with-androidjunitrunner-1-0-0-and-assertj A few days ago, Android Testing Support Library 1.0 was released. I pick up some awesome stuff for me, and I think this release will help enhance test automation for other 3rd party libraries. https://android-developers.googleblog.com/2017/07/android-testing-support-library-10-is.html https://developer.android.com/topic/libraries/testing-support-library/release-notes.html IdlingResources…More