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.

Advertisements

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

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

Read “Antifragile Systems and Teams”

I read Antifragile Systems and Teams. Entirely, this book is DevOps book, I thought. This book also short. So I just left some lines in this article and I’ll leave here.

Anyway, do you heard Antifragile? I hadn’t known the word before.

Let refer the Taleb’s word from a book.

“Some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. Yet, in spite of the ubiquity of the phenomenon, there is no word for the exact opposite of fragile. Let us call it antifragile. Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better”
> https://en.wikipedia.org/wiki/Antifragile

As the word said, antifragile is anti + fragile. But it isn’t not fragile. It’s more robust and resilient thing. And this book tried to show how to build such systems/teams, especially software development industry.

Lately, I believe DevOps methodology became common. We can imagen agile, flexible, robust and autonomous things. And this book also challenges to show use cases and examples for it.

What I surprised was I saw QA(Quality Assurance) related engineers often appeared. I thought this kind of books shows some ideal story, but this book was more close to real DevOps story. I also read DevOps and Testing books as same as this book.

This book is too short. Only 20 pages in PDF and they were summarised good enough things. So, if you have an opportunity to read it, let’s read it.

See you happy DevOps? 🙂

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

[iOS]xccov and JSON format

Before Xcode 9.2, we can get formatted coverage data using https://github.com/SlatherOrg/slather, for example. The library formats llvm-cov.

But from Xcode 9.3, xccov is introduced officially. The command can run via xcrun.

xccov is a new command-line utility for inspecting the contents of Xcode coverage reports. It can be used to view coverage data in both human-readable and machine parseable format. To learn more, enter man xccov in Terminal. (37172926)

I tried the feature with https://github.com/KazuCocoa/test.examples and I put a simple Ruby gem script to get the target name and the line coverage.

Run

$ git clone https://github.com/KazuCocoa/test.examples && cd test.examples
$ xcodebuild -workspace test.examples.xcworkspace -scheme test.examples -derivedDataPath Build/ -destination 'platform=iOS Simulator,OS=11.3,name=iPhone 7' -enableCodeCoverage YES clean build test CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO
$ xcrun xccov view --only-targets --json Build/Logs/Test/*.xccovreport > result.json

Get JSON

We can get some kind of format.

# Output: https://gist.github.com/KazuCocoa/40eaa3ac9de5e52c1a3795c49657dd4b
$ xcrun xccov view --json Build/Logs/Test/*.xccovreport | jq .

# Output: https://gist.github.com/KazuCocoa/879554e02934d368f976959d3f8cec4b
$ xcrun xccov view --only-targets --json Build/Logs/Test/*.xccovreport | jq .

Parse the JSON with Ruby

parsed = Xccov::Parse.new(file: './result.json')
parsed.targets_line_coverage["test.examples.app"] #=> 0.35

Conclusion

From Xcode 9.3, we can get formatted coverage data using xcrun command. I’ve seen some scripts use Slather and Nokogiri to handle XML format and collect them. But the script will be more simple. Does this make you happy?