[automation]try Katalon

https://www.katalon.com/

これを少し触ってみた。

感想としては、これは

https://docs.katalon.com/display/KD/Installation+and+Setup

以下の結果を参考にすると良さそう。

このツールの目的は、Selenium/Appiumを使ったテストを記述/管理する労力を減らそうというものぽい。特に、コードを自分で書かなくて良い状態で。
なので、以下の比較を見るとわかるのだけれど、例えば専属の自動化エンジニアを抱えるところとか、そういうところはターゲットではないように見える。

https://www.katalon.com/blog/comparison-automated-testing-tools/

Emerging solution with a small community.
Feature set is still evolving.
Lack of choices for scripting languages: only Java/Groovy is supported.

Allure2が開発途中だった

Test reporterの生成で有名どころと言えばAllureがありますね。Yandexのメンバが開発しているやつです。

最近、そのv2が開発されていることを知りました。

https://github.com/allure-framework/allure2

Gradleを使っていたので、早速Forkして使ってみることに。
人が増えて、テスト結果を複数人で見る必要が出てきた時に、こういう結果レポートから情報をざっと見ることができるツールはとても重宝しますね。

受託系の人たちはこういうことを欲する一方、Web系の人はそうでもない人も多いように見えます。
ただ、実施時間など含めて色々とまとめて情報をみたい場合、このようなUIを持ったツールは役に立つものです。

[iOS]Bluepill1.0.0

Bluepillの1.0.0がリリースされていたのでメモ。

XCUITestサポートが少し前に完了し、1.0.0になったようですね。

https://github.com/plu/pxctest/releases

こちらに比べて、さすがに企業としての投資が違うのか、開発がBluepillの方が活発だ…

[java]Parameterized test with JUnit4.12

最近知ったのですが、JUnit4のParameterized.classに name 属性を付与できるようになったのですね。

エラーの可読性などを見ると、組み合わせテスト用のDataPointsを使ってしまう面もありましたが、name属性が付与されるようになったことで、パラメータ化テストではParameterized.classをそのまま使えそう。

なるほどね…

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

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

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

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


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