[Android]Change locale with Android O

The method of changing locale changes in Android O.

+        if (Build.VERSION.SDK_INT >= 26) {
+            // getConfiguration moved from ActivityManagerNative to ActivityManagerProxy
+            activityManagerNativeClass = Class.forName(amn.getClass().getName());
+        }

Appium has already supported the change.


[Android]Jetpack for test related environments

I’ve bet Truth since [Android]Checking Android Testing Support Library 1.0. I encountered an issue using AssertJ with ATSL 1.x and I talked about it in https://www.slideshare.net/KazuMatsu/20171215-andoirdtestnight before.

In a talk https://www.youtube.com/watch?v=wYMIadv9iF8 , Google starts to provide Jetpack. The pack has various libraries and test related libraries as well. For example, Espresso.

What I surprised is Truth Android extension. They announced the extension will be bundled in the pack. It means they will bundle Truth as an assertion library for Android. For me, the news was very good opportunity since it shows my prediction was a success.

Robolectric 4.0, Nitrogen and AndroidTestOrchestration were also interested.

We can see an announcement of Robolectric in http://robolectric.org/blog/2018/05/09/robolectric-4-0-alpha/ . According to the release note, we can implement test code like instrumented tests but can handle it via Robolectric. In the video, we can hear running test in no emulator environment and I predicted it was this feature. Recent years, Googlers have committed to Robolectric heard and I also thought it would integrate to one of the testing libraries.

class OnDeviceTest {
  @get:Rule val rule = ActivityTestRule(NoteListActivity::class.java)

  @Test fun clickingOnTitle_shouldLaunchEditAction() {

I’ve noted some interesting things for me in the Google IO especially test.

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


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.


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

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.

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.

[Appium]get performance for iOS

So long ago, I tried to monitor iOS performances using instrument commands. But I gave up once because of host machine’s load.

But https://github.com/appium/appium-xcuitest-driver/pull/637 is created and that is awesome…

I just remember seeing the PR and I’ve published this article in my memory…

Note for image comparison based on JS lang

Note for me.

Image/Visual comparison tools.

The reg-suit is https://github.com/reg-viz/reg-suit .

The kobold is https://github.com/yahoo/kobold .
The kobold’s diff engine is https://github.com/yahoo/blink-diff .
I’ve been using it for a long time for comparing snapshots.

[Flutter]Flutter app with Appium

I touch [Flutter]some thoughts for the Flutter (v0.1.0) before. And this time, I tried to run the app with Appium.

We can run UI test with Appium as well as native apps. But Flutter apps have no accessibility identifier and customised resource id. So, it’s quite difficult to implement robust test automation scenario so far.


Probably, Appium is easy to kind of automation than Espresso/XCUITest so far.

Taste mabl which provides ML-driven test automation service

Lately, ML related technologies step into industry section and many engineers challenge to integrate them into their services.

The movement also comes into test/quality industry. I also have some ideas to use them though.

A few weeks ago, I found a service which named mabl which provides ML-driven test automation service. The service run tests using ML technologies, not test ML technologies itself. I try the service recently and put some results and thought here.

URL: https://www.mabl.com

The target URL is simple, https://www.google.co.jp

I don’t do anything except for input the URL into a particular area. Then the journey started and I just wait for a while.

The site looks crawling the target site and checking all links. The followings are the results. I can see some error message which may be broken links.

Screen Shot 2018-02-27 at 10.22.02

Screen Shot 2018-02-27 at 9.34.37

In test section, we can see some test cases and its results. Their test cases are generated automatically. According to the titles and some logs, the test aims to collect available transitions, it means available links and some data.

Screen Shot 2018-02-27 at 10.21

We also can see train section. I guess the section is a teacher in ML world. So, we running test iteratively, then the ML logic learns the test target and they will be able to conduct automated test efficiently.

Screen Shot 2018-02-27 at 10.22

Screen Shot 2018-02-27 at 10.23

I believe if we run test iteratively and collect test data, cases and results, the ML will be more inteligent and they can run test automatically effective.

Anyway, it looks promising and I’d love to try my thought using ML technologises.

Read a part of “Practical Monitoring”

I was interested in the book for a long time. The O’Reilly has published a part of the book and I also read it to know the book.

Practical Monitoring

Just I read only one section. I couldn’t more monitoring stuff in this book, but I got some antipatterns.

  • Anti-Pattern #1: Tool Obsession
  • Anti-Pattern #2: Monitoring-as-a-Job
  • Anti-Pattern #3: Checkbox Monitoring
  • Anti-Pattern #4: Using Monitoring as a Crutch
  • Anti-Pattern #5: Manual Configuration

When I read the above sections, I can imagine why they are the antipatterns. Some of them have similar issues creating the autonomous team.

In short, to scale the system, we must make the system automate. And the book should have many practices of the monitoring.

Anyway, we should take care monitoring stuff as well.