[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 "com.example.test" 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

“異文化理解力”を読んだ

異文化理解力を読んだ。

現在、新しいチームの立ち上げとして異文化の環境で活動を始めている。
その中で、単なるGitHubなどの上での活動ではなく、直接議論したり、対話したりする必要がある。

この書籍自体を信じるすぎることは、特定の文化などへのステレオタイプを生むことになったりとマイナスな面もある。そのため、こういう面もあるという一つの意見としてしる、に止めることが大事だと思う。そのため、そのことを考えながら読んでいた。

異文化を考えるときに考慮した方が良い指標として、以下をこの書籍では言及している。

  1. Communicating
  2. Evaluating
  3. Persuading
  4. Leading
  5. Deciding
  6. Trusting
  7. Disagreeing
  8. Scheduling

この中では、日本も多々出て来ていて、日本やアジア圏はハイコンテキストな文化というような、自分でも納得するような見解も述べられている。一方で、日本人でも自分の周辺は少し雰囲気が異なる面もいくつかあり、やはり1つの意見として触れる方が良いという感じ。

また、フィードバックを行うときなど、”ネガティブさ”を強調する、弱める言葉がある。フィードバックは大事だが、簡単に関係を壊したり、逆に意図が伝わらないことも多い。そのためこういう言葉を使いつつ、ちゃんと伝える/和らげることを覚えたい。

批判を和らげる言葉としては: kind of, sort of, a bit, maybe, slightlyなどがある。
批判を強める言葉としては: absolutely, totally, stronglyといったお馴染みの言葉が並ぶ。

多分化なチームはやはりコミュニケーションコストが増える。そのため、時間を節約したいのであれば文化の違いを抑える構成にする必要がある。一方で、イノベーションや創造性といったところを時間の節約以上に重視するのであれば文化の多様性を、プロセスをしっかりした上での取り入れると良い。

このような視点からも、この異文化というものは見て取れることができる。

信頼の形もいくつかあって、1. cognitive trust(認知的信頼) , 2. affective trust(感情的信頼)にも分けられる。

これは、前者はタスクのような認知されるものをベースにする一方、後者は関係性といった要素をベースにする。つまり、業績や技術といった確実性に対する確信に基づく信頼と、親密さや共感・友情といった感情から形成されるものに分けられる。

全体を通して、日本に関して言及しているものの中でも納得できるもの、できないものもあった。そのため、やはりステレオタイプではなく、全体としてこういう 多様さがある ことを認識する1つの意見と理解するのが良いのだと思えた。

英語で対話することが中心になるため、他者にも伝えることができるようにこの書籍の原書よりも少し新しい、英語の The Culture Map を読んでみようかと思っている。

[Kotlin]Kotlin in Actionをようやっと終えた

長らく読んでいたのですが、Kotlin in Actionをようやく読み、写経などし終えた。
他にも同時にやっていたとはいえ、このときからすると時間としては結構長かった…

ただ、Kotlin全体の形や、以下のような処理を書いたりしてというところが理解・発想できるようになったぶん、読んで全体を知ることはよかったかなと思います。

以下は、KotlinでSpekといった大きなライブラリを使うほどではないけれど、テストにコンテキストを持ち込みたい時なんかにプロジェクトに書いておくと良いのではないかな、と思うやつです。

class Then {
}

class When {
    fun then(description: String, then: Then.() -> Unit) {
        then.invoke(Then())
    }
}

class Given {
    fun `when`(description: String, `when`: When.() -> Unit) {
        `when`.invoke(When())
    }
}

fun given(description: String, given: Given.() -> Unit) {
    given.invoke(Given())
}

given("description for given") {
  `when`("description for when") {
    then("description for then") {
      println("finish")
    }
  }
}

KotlinだとWhenが予約語になっているので、Spekででもなのですが、Given/On/Itスタイルにすると良さそう。

class It {
}

class On {
    fun it(description: String, it: It.() -> Unit) {
        it.invoke(It())
    }
}

class Given {
    fun on(description: String, on: On.() -> Unit) {
        on.invoke(On())
    }
}

fun given(description: String, given: Given.() -> Unit) {
    given.invoke(Given())
}

given("description for given") {
  on("description for on") {
    it("description for it") {
      println("finish")
    }
  }
}

すぐに書くことはできるものですが、一応、ここではライセンスをMIT Licenseにしておきます。

The MIT License (MIT)

Copyright (c) 2015 Kazuaki MATSUO

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

[Android]composer and swarmer

I’ve posted [Android][iOS]Awesome tips about composer and swarmer.

The following is my trial with them.

https://github.com/KazuCocoa/run_parallel_tests_android

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

IdelingResources

help synchronise against

  • Executors
    • com.android.support.test.espresso.idling:idling-concurrent:3.0.0
  • network requests and responses
    • com.android.support.test.espresso.idling:idling-net:3.0.0

New view matchers/actions/methods

Parameterised testing

GrantPermissionRule

Understand how to write/think test for Android

Android Test Orchestrator

Runner related command options

  • -e classLoader – Provide the ability to pass class loaders using runner args
  • -e filter – Add support for custom JUnit filters to be specified using runner args
  • -e runnerBuilder – Allows developers to provide their own implementations of RunnerBuilder that can determine whether and how they can run against a specific class

[Erlang][Software Test]Property-based testing/QuickCheck Testing

I often see Property-based testing recently, and the following article is useful to understand what property-based testing and quick check testing is I’ve read for a few years.

PropEr Testing
http://propertesting.com/

I use QuickCheck testing in my work, and it works fine against functions especially stateless ones.

[iOS]Large Photo Libraries for Testing

from https://developer.apple.com/videos/play/wwdc2017/505/

If you’d like to test with a large number of photos, you can generate dummy photos by https://developer.apple.com/sample-code/wwdc/2017/Creating-Large-Photo-Libraries-for-Testing.zip . Download it and run on the target device.

The app is presented in https://developer.apple.com/videos/play/wwdc2017/505/ .

https://developer.apple.com/documentation/photos/phasset

[Android][iOS]Awesome tips

Headless simulators

Appium(with WDA) can run headless simulators isHeadless against Xcode9+.
Awesome: https://github.com/appium/appium-xcuitest-driver/pull/472/files

composer, swarmer and mainframer

Replace Spoon for Espresso.

[Mobile]Security Testing tools

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