[Android]Use PermissionRequester to get permissions

I’m using composer to handle instrumented tests.

GrantPermissionRule has introduced for the andorid test support library, [Android]Checking Android Testing Support Library 1.0. The Rule work as @Rule in JUnit4.

We’d like to clean screenshots every time. But we need some permissions to clean them. To achieve it, we can use PermissionRequester to get permissions.

In my case, I run this in Runner and before starting test cases.

fun clearComposerScreenshots() {
  val requester = PermissionRequester()
  requester.addPermissions(
    android.Manifest.permission.WRITE_EXTERNAL_STORAGE,
    android.Manifest.permission.READ_EXTERNAL_STORAGE)
  requester.requestPermissions()
  val spoon = Environment.getExternalStoragePublicDirectory("app_spoon-screenshots")
  val deleteRecursively = spoon.deleteRecursively()
  val result = if (deleteRecursively) "success" else "failure"
  Log.i(TAG, "clearing screenshots from folder ${spoon.absolutePath} $result")
}

https://github.com/KazuCocoa/EspressoEnv/pull/5 is an example to use the above in Runner.

Advertisements

[iOS][Appium]Process Arguments by Appium for XCUITest, iOS

Today, I’d like to leave a tip. I’ve implemented test cases using this article for over 3 years. It helped us to control test environment more stable and fast.

XCUITest can set process arguments for Instrumentation.

According to https://github.com/appium/appium-xcuitest-driver#desired-capabilities, you can set processArguments in capability and the test app can get the value via ProcessInfo.

You can set the value via below’s Environment Variables.

Screen Shot 2018-06-10 at 20.54.14

Client

Next code is Ruby based.

IOS_OPS = {
  caps: {
    platformName: :ios,
    automationName: 'XCUITest',
    ...
    processArguments: {
      env: {
        "PROCESS_VALUE": "process value"
      }
    }
  },
  appium_lib: {
    ...
  }
}.freeze

By processArguments, you can set the environment variables.

Test app

The processArguments can get via ProcessInfo like below.

import Foundation

let env = ProcessInfo.processInfo.environment
env["PROCESS_VALUE"] // "process value"

Next image isn’t the above. But I believe it help you understand ProcessInfo.processInfo.environment.
Screen Shot 2018-06-10 at 20.15.50

You can control some behaviour using the argument. For example, URLs or interval for network.

Read “Continuous Delivery with Spinnaker”

I read Continuous Delivery with Spinnaker to catch up with Spinnaker and the bases.

Recent my profession is mobile, but I have some experience/knowledge of distributed systems since I studied the Byzantine General Problems in my university. And I also has caught up with network/tools/fundamentals associated with it. (Especially testing and monitoring topics.)

You can learn current problem an solution for continuous delivery against cloud-based complex environments with Spinnaker.

In chapter 1 to 4, you can learn the basic concept of continuous delivery and the current cloud-native world. For example, pipeline-related topics. The pipeline is development pipeline from implementation to deployment through testing.

The testing is not only development testing but also testing in production like Chaos and Canary.
We have two main triggers to kick the pipeline. One is time base, and another is event based. The time base is manual or cron. The event base is git, continuous integration, docker or pipeline.

After chapter 5, you can learn the more real usage of Spinnaker. Of course, you can also know Kubenetis since it is a part of deployment toolset in spinnaker.

From chapter 11, you can learn additional tips for Spinnaker.

This book helps you to understand current problem an solution for continuous delivery against cloud-based complex environments with Spinnaker as I addressed in the above.

For me, it’s significant excited topic about complex/chaos system related problems and how to solve them. So, I enjoyed learning the book.

[Android]some mocking features work only on Android P+

One of my colleagues told me Mockk. The library is pure Kotlin mocking library. An interesting thing for me is Android instrumentation support.

I had a question when I saw that why Android P was a limitation. Since it provide mocking feature for final classes / objects in instrumentation tests.

I investigated a bit and I found interesting issues. So I left them here for my memo.

Mokito

Dexmaker

Create a PR to update outdated libraries by script

Updating outdated libraries is important. Longtime outdated libraries probably lead difficult updating libraries. Sometimes they have breaking changes. We can reduce the risk updating libraries frequent and keep them small size.

Meanwhile, it’s difficult to catch up with ALL outdated libraries and updating them frequently. Since our works aren’t only updating them.

Get outdated libraries by anticuado

I’ve created https://github.com/KazuCocoa/anticuado to help get outdated libraries. Using the library, you can get outdated libraries as JSON format. Currently, the library supports the below.

  • Java
    • Gradle
  • iOS
    • CocoaPods
    • Carthage
  • Ruby
    • Bundler
  • Elixir
    • Hex
  • JavaScript
    • npm
    • yarn

How to use it

For example, you can run it against cocoapods.

require "anticuado"

cocoadpos = ::Anticuado::IOS::CocoaPods.new "path/to/project"
outdated = cocoadpos.outdated 
cocoadpos.format outdated

The output is the below.

[
  {
    library_name: "AFNetworking",
    current_version: "2.5.0",
    available_version: "3.1.0",
    latest_version: "3.1.0"
  },
  {
    library_name: "OHHTTPStubs",
    current_version: "4.1.0",
    available_version: "5.0.0",
    latest_version: "5.0.0"
  }
]

You can run it on CI services like Jenkins and send them to your slack channels.

Create a new PR automatically

Lately, I’ve added a feature to create a PR which include updating outdated libraries. The below is an example of cocoapods. The target repository is https://github.com/KazuCocoa/test.example. The result is https://github.com/KazuCocoa/test.examples/pull/2

If you have CI environment, automated tests should run after creating the PR. If they are green, you probably can merge it to master branch.

As a result, you can reduce the work to update outdated libraries by yourselves.

conclusion

The update logic is not complicated, but the tasks drain our time. This kind of work will improve your development environment step by step, I believe.

[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.
https://github.com/appium/io.appium.settings/blob/dc2cb22e1a2cb565fa49f0c56d00c604867554b5/app/src/main/java/io/appium/settings/handlers/LocaleSettingHandler.java#L57

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

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

  @Test fun clickingOnTitle_shouldLaunchEditAction() {
    onView(withId(R.id.button)).perform(click())
    intended(hasAction(equalTo("android.intent.action.EDIT")))
  }
}

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.

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

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.