[Android]Use apkanalyzer to get apk data

It’s important to make configurations programmable to manage them codebase and enhance automation. Android has provided apkanalyzer to analyse test target apks easily. Before the command, we use aapt for example. But with the analyzer command, we can get apk related data from target release apks easily.

https://developer.android.com/studio/command-line/apkanalyzer

The below is a simple wrapper for adb and apkanalyzer written in Ruby. I’ve used it to integrate adb commands to integrate Ruby test code.
https://github.com/KazuCocoa/droid_adbs/

https://github.com/KazuCocoa/droid_adbs/blob/master/test/droid_adbs/analyzer_test.rb

Advertisements

Read “A Practical Guide to Testing in DevOps”

A couple of weeks ago, I read A Practical Guide to Testing in DevOps

The book explained and described DevOps x Testing with many references and keywords.

you can see why people struggle to understand where testing fits in a model that doesn’t mention it at all. For me, testing fits at each and every single point in this model.
> by Dan Ashby


Continuous Testing in DevOps…

In the book, we can see many words, beyond the team boundary. We can see explanations about separated test teams and activities in many traditional style world. But recent Agile and DevOps culture breaks the separations. It is the natural thing.

We can see some concrete steps about pair work and test activities. For example, first 10 min …, next 20 min is… etc. We can image how to work them in our activity quickly, I believe.

Comparing testing too deeply or too shallow also helps us.

The book is useful to understand recent development and testing culture. And almost stories were very proper for my current environment. I had some unknown words, but we’ve been working such things and knew the word and definitions.

I’d love to recommend this book to other guys who would like to catch up with recent development style include testing.

[Android]New release of ATSL and new feature of composer

Lately, I’ve been using composer to run instrumented tests in the Android world. ([Android]composer and swarmer)

Today, I just found an interesting PR. => https://github.com/gojuno/composer/pull/138

The PR is emulating the behaviour like AndroidTestOrchestrator. As you know, the orchestrator has some limitations and it includes Parameterized tests aren't currently supported. It is JUnit4’s feature. So, the test support library has introduced JUnitParams.

The PR also has the same limitation. My project has been introduced the new Params so we don’t affect the limitations. But if you’d like to introduce the new composer’s feature, you should take care it.

I also just found interesting news.

Espresso 3.0.2, Runner 1.0.2, Rules 1.0.2, Monitor 1.0.2, AndroidTestOrchestrator 1.0.2 (2018-04-24) have been released!
https://developer.android.com/topic/libraries/testing-support-library/release-notes

They have some good improvements and fixes. For example:

  • Espresso 3.0.0 should NOT depend on test runner
  • ActivityTestRule doesn’t update Activity instance during configuration changes
  • Pass -e clearPackageData flag if you wish the orchestrator to run pm clear context.getPackageName() and pm clear targetContext.getPackageName() commands in between test invocations. Note, the context in the clear command is the App under test context.

etc.
Reading the release note, they fixed and improved many things for AndroidTestOrchestrator. That is brilliant.

[Appium]Image comparison with Appium and other libraries

In general, we compare two images when we’d like to detect differences between them in visual.

I believe OpenCV and ImageMagick are famous tools to achieve the purpose lately. But sometimes we faced building errors, for example. So, I’ve used a simple enough comparison tool. That is Kobold. The library uses blink-diff as a comparison engine. The library provides some features to configure how to compare each other.

I’ve published Ruby wrapper to use them.

And you can also see some articles for it on this site. (Most of them are Japanese, and you need to translate though…) Link

By the way, I also researched some similar and straightforward libraries. I believe perceptualdiff also a famous library. I compared ImageMagick and perceptualdiff a bit before.

A few years ago, I started to investigate OpenCV, opencv_sample is one example, to make such comparison more flexible. The reason why I investigated it is many guys have been implemented Machine Learning / Deep Learning features in it. So I’ve believed it helps us.

And lately, Appium is going to support OpenCV based comparison features as one of the fundamental features. https://github.com/appium/appium-support/pull/65 is the brilliant PR. We can use some OpenCV features via them. We are also able to get diff images to ensure the results in visual.

The feature will help many users who would like to get image comparison easy.

Actually, to make test suites stable, separating steps are important like:

  • Conduct test cases and assert the results without image comparison
  • Compare images
  • Collect and save the results

Otherwise, the new Appium feature will encourage automation more, I believe.

[Elixir]property based testing with stream_data

Elixir will bundle property-based testing in the core.
http://elixir-lang.github.io/blog/2017/10/31/stream-data-property-based-testing-and-data-generation-for-elixir/

We can see the prototype for the library from https://github.com/whatyouhide/stream_data .

The following lines are the example I applied the library before.

  use ExUnitProperties

  property "get body" do
    check all body <- StreamData.binary(),
              max_runs: 50 do
      value = %{"request" => %{"method" => "GET",
            "path" => "/request/path", "port" => 8080},
            "response" => %{"body" => body, "cookies" => %{},
            "headers" => %{"Content-Type" => "text/html; charset=UTF-8",
              "Server" => "GFE/2.0"}, "status_code" => 200}}
      assert Body.get_body(value) == body
    end
  end

https://github.com/KazuCocoa/http_proxy/pull/47/commits/11bf6ff5a763c97c3ec6c7bc4a1811de53a6d0c2

We can see more details from https://hexdocs.pm/stream_data/StreamData.html and you can see how flexible the methods.

Watching FB’s Android at Scale

I watched FB’s Android at Scale: https://code.facebook.com/posts/1958159731104103/android-scale-2018-recap/

I put my memo which I got interested in.

Automated Testing Practices @ Scale: Waseem Ahmad, Facebook

I know almost tips and same thought.

App Modularization and Module Lazy-Loading: Mona Huang, Instagram

  • How they separate their modulized app
  • How to separate their module to fit their structure

Screen Shot 2018-02-07 at 22.56.47

Model-View-Presenter @ Scale: Sam Thompson and Zach Westlake, Pinterest

  • Their Engineer increase and they have 40+ engineers in 2016
  • Their Approach

Screen Shot 2018-02-07 at 23.13.50

Screen Shot 2018-02-07 at 23.20.27

Screen Shot 2018-02-07 at 23.22.58

Conclusion

My company and team also start trying same thing and way to go.
Hopefully, some of our members talk our activities and tips publish to the world…

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

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など含めてモックライブラリなどのライブラリを追うと良いでしょう。様々な、それぞれ使用感の異なる多様なライブラリに出会い、それぞれの良し悪しを学んだりできるかと思います。

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

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

[Android]Run orchestrator 1.0.0

Download apks from maven:

And install them and start the process like https://developer.android.com/training/testing/junit-runner.html

adb install -r path/to/orchestrator-1.0.0.apk
adb install -r path/to/test-services-1.0.0.apk

# Replace &quot;com.example.test&quot; with the name of the package containing your tests.
adb shell 'CLASSPATH=$(pm path android.support.test.services) app_process / \
  android.support.test.services.shellexecutor.ShellMain am instrument -w -e \
  targetInstrumentation com.example.test/android.support.test.runner.AndroidJUnitRunner \
  android.support.test.orchestrator/.AndroidTestOrchestrator'

If you have a custom runner, you can replace android.support.test.runner.AndroidJUnitRunner to yours.

After the above, you can start instrumentation tests via the orchestration layer.

./gradlew connectedAndroidTest

[Kotlin]SoftAssertions with Kotlin and AssertJ

Hi there,

Do you know soft assertions provided by AssertJ?

In many cases, one test case has one assertion.
But sometimes we’d like to collect some assertions within one assertion, and then we can use SoftAssertions() for the purpose.

Of course, we can use AssertJ in JUnit. In addition, we can use it in Kotlin like the following.

SoftAssertions().apply {
  assertThat(1 + 1).isEqualTo(1)
  assertThat(1 + 3).isEqualTo(2)
  assertThat(1 + 1).isEqualTo(3)
}.assertAll()

So useful syntax 🙂

[iOS][EarlGrey]Run tests quickly

Small, small tips to enhance conducting speed for EarlGrey.
In many cases, iOS can’t handle animation speed such as Android even UI Test cases.

EarlGrey available changing animation speed except for UIScrollView. here

// Swift
let kMaxAnimationInterval: CFTimeInterval = 5.0
GREYConfiguration.sharedInstance().setValue(kMaxAnimationInterval, forConfigKey: kGREYConfigKeyCALayerMaxAnimationDuration)

// Swift
GREYTestHelper.enableFastAnimation()

https://github.com/google/EarlGrey/blob/master/docs/faq.md

In XCUITest case:

# swift
UIApplication.sharedApplication.keyWindow.layer.speed = 100