[iOS]run tests on simulators vol2

[iOS]Run multi simulators with FBSimulatorControl
にも書いている、iOSシミュレータを1つのマシンで複数動作させるやつ。最近ではLinkedInからOSSが公開されましたね。Blogはこちら。スターも多く、さすがLinkedInという感じ。

社内で FBSimulatorControl ベースの複数シミュレータで実行する環境を作ろうと思っていたけれど、もっと素晴らしいものが世に出てきててオォォォという感じ…(私、価値出せてない…)
ここら辺、実装能力が顕著に現れて私は本当にまだまだと思う一方です。。。

以下、以前からある類似のものをピックアップ。

類似

これを実施していると、正直なところ並列実行できないCloud実行環境はイマイチですね。
ローカル環境強し。。。

Architecture for GUI Testing(mobile)

In 2014, I talked about GUI testing architecture.

Recently, someone asks me about the architecture.So, I post the blog about it.

The following flow means the architecture. I think this architecture is common if anyone uses libraries such as Cucmber.

  Scenario     Abstract     Wrapper    Binding     Appium
(*.feature)   (*_steps.rb)  (*.rb)
     |           |            |           |          |
     |---------->|            |           |          |
     |           |----------->|           |          |
     |           |            |---------->|          |
     |           |            |           |--------->|
     |           |            |           |          |
     |           |            |           |<---------|
     |           |            |<----------|          |
     |           |<-----------|           |          |
     |<----------|            |           |          |
     |           |            |           |          |
  • Scenario layer
    • Describe scenarios.
    • This layer depends on “User scenarios”.
  • Abstract layer
    • Implement steps to run scenarios as Ruby code.
    • This layer absorbs the changes in scenarios.
  • Wrapper layer
    • Wrap binding.
    • This layer absorbs the changes in bindings.
  • Binding layer
    • Ruby binding

PageObject pattern is very famous. In this case, scenairo layer and abstract layer depends on pages. BTW, wrapper layer is common methods to help other layers.

[Android][Accessibility]accessibility check in Espresso

Androidでは、以下のようにしているといくつかのAccessibilityCheckをEspresso実行時にViewに対してチェックしてくれます。

import android.support.test.espresso.contrib.AccessibilityChecks;

@RunWith(AndroidJUnit4.class)
@LargeTest
public class AccessibilityChecksIntegrationTest {
    @BeforeClass
    public static void enableAccessibilityChecks() {
        AccessibilityChecks.enable();
    }
}

これに似た機能をEarlGreyでも実現してほしいというissueが立ってました。
https://github.com/google/EarlGrey/issues/393

ここら辺をうまく拡張していくと、自分たちの組織におけるViewなどのチェックを拡充していくことができるのでないかなーと期待。

[React][iOS][Android]Try ReactNative + TypeScript

以下を参考に、ReactNative + TypeScriptでアプリを書いてみる。
ReactNativeでは testID としてiOSはaccessibilityIdentifier、AndroidはView#setTag/getTagが使われている。(ただ、2016/9ごろにAndroidに対してresource idを付与できるようになったとあったので、ReactNativeでもresource idベースでも今後は大丈夫かも)

以下を参考にした。環境構築周り。


ただ、上記のどれもそのままでは動作しなかったので、本格的にはまだ触っていない。

「消極性デザイン宣言」を読んで、approchiabilityという言葉を知った

消極性デザイン宣言-消極的な人よ、声を上げよ。……いや、上げなくてよい。」を読みました。

シャイハック。
私自身、ここに書かれていたように消極的な人間で、V字タイプな人。少人数や大人数だとある程度大丈夫だけれど、微妙な人数になると「・・・」となるような。

そんな人たちのコミュニケーションの話から入り、だんだんとモチベーション、インタラクションの話へと内容が移ってきます。個人的に面白かったのは、approchiabilityという考え方と、モチベーションの話。ここのモチベーションはやる気を出していく話ではなく、やる気がわかないことを前提とした(意識の低い)モチベーションの話なので、疲れず良かったです。

人間は基本的には消極的

これが基本的な立ち位置でした。消極的なので、自然にできるようにどうデザインするかとか、そういう話になってきます。

機能があることではなく、”機能する”こと、その機能を使おうとしやすいことなど。

Usability と Approachability

Usabilityは使いやすさとしてよく言われます。品質の話になるときや、人間工学の話、デザインの話といったように様々なところで出てきます。一方、Approachabilityという言葉は私が把握している限りでは初耳でした。

Usabilityとの対比としては、Usabilityが製品/サービスそのものの使いやすさを評価の対象とするのに対して、Approachiablityは対象となる製品/サービスがどれだけ”使おうとしやすいか”を評価しようとしている、という感じ。なので、製品/サービスのその周辺から連続した出来事を評価の対象に加えるという感じでしょうか。モバイル端末などの使いやすさとしてはこういった連続性に言及しているものもちらほら見ますが、そこに焦点を当てたものがこの”Approachiablity”という感覚を受けました。

使おうとしやすさ、行為の切り替え・接続、やめやすさ、いかに無理せず自然とできるか。

特別ではなく日常に溶け込む系のサービスとか製品ではこういう考え方って大事なデザインの話になりそうですね。

そういえば、インタラクションデザインにも言及していて、その中であったモチベーションの設計は色々なところで関係しそうな感じがしました。

締め

こういう書籍は時折読みますが、Approchiabilityという言葉の定義はなかなか良い発見でした。

[Design][iOS][Android][windows]

メモ

[ReactNative][Appium]testIDの振られ方

ReactNativeだと、 testID としてiOSだとaccessibilityID、Androidだとview tagを使ってIDを埋め込むのですね。なので、ReactNativeのアプリに対してidで要素を検索したい場合はAndroidだと特に従来のAppiumやEspressoとは少し異なる。

Appiumだと、以下でview tagの取得をサポートするらしい。

これつくと、resource idが同じ要素も細かくidを振って操作することもできるようになるので、安定性向上に寄与しそうですね。

Does EarlGrey support finding react-native elements?
https://github.com/google/EarlGrey/blob/master/docs/faq.md

react native