[ReactNative][Test]Detox instead of Appium

2017/06/08現在

過去、ReactNativeに対するUITestに関して書いていたのですが、今の段階ではAppiumよりはDetoxを使うほうが、JSを経由したテストツールとしては良さそう

EarlGreyも参考にしている所とかあり、より安定したUIテストを実施するには現実的な気がします。
Androidのサポートも計画されているので、必要に応じてコミットしたいですね。

参考: [ReactNative][Appium]testIDの振られ方

Netflixの複雑なマイクロサービスに対するテスト自動化

とても面白い。

Netflixの、マイクロサービス環境下におけるテストの複雑さを解決しようと取り組んでいたことの内容と、その1年の成果が書かれている。

here

読んでいてもとても面白く、テストエンジニアという立場からすると純粋にとても挑戦的に面白い内容だと思った。

また、社内の利用をより簡単に、利用者に負担をかけない取り組みも良いですね。
カッコ良い。

RedwoodHQ on Mac

http://qiita.com/ootaken/items/e6e85e7b91cb98b2e294 で知ったのですが、RedwoodHQというOSSのtest automation frameworkというものがあるらしいですね。

https://github.com/dmolchanenko/RedwoodHQ

Webページを見るとどうやらサーバの動作環境のメインはWindows環境。
ただ、githubを見る限りはJavaとNodeぽいのでmacでもちゃんと動くだろうと思って動かしてみました。

必要だったこと。

  1. mongodbをインストールする

それ以外は、基本的に

  1. git clone する
  2. top directory で npm install する
  3. mongod を起動した上で、 node app.js
  4. agent配下で npm install
  5. node app.js (in agent)

これで、

にアクセス可能になります。
ただ、私の環境ではAgentへのアクセスの時にサーバからの応答はあるのですがページが表示されなかったので(not foundが返ってくる)、うまく動いていない部分があるのかもしれないです。そこらへんは少し見てみないといけなさそうでした…

Screen Shot 2016-02-24 at 07.19.40

Pairwise with Pict on Mac

Pict is one of famous tool for Pairwise. The tool is open sourced by Microsoft. See https://github.com/Microsoft/pict.

Pairwise is combinational tool.

Usage

$ git clone https://github.com/Microsoft/pict
$ cd pict
$ make
$ ./pict

Pairwise Independent Combinatorial Testing

Usage: pict model [options]

Options:
 /o:N    - Order of combinations (default: 2)
 /d:C    - Separator for values  (default: ,)
 /a:C    - Separator for aliases (default: |)
 /n:C    - Negative value prefix (default: ~)
 /e:file - File with seeding rows
 /r[:N]  - Randomize generation, N - seed
 /c      - Case-sensitive model evaluation
 /s      - Show model statistics

Then you can run test with…

$ ./pict  doc/sample-models/strncpy.txt

Let’s use Pairwise on UNIX/Linux 🙂

[iOS]UIAutomation will be going away and focused on XCUITest

そこまでXCUITestを調べてなかったのですが、最近のFacebookのWebDriverAgentに少し気になるissueのコメントを見つけました。

issueはこちら。 いくつかピックアップすると、

There are a number of limitations currently with XCTUI testing, but we will need to start with the groundwork, since it’s possible that UIAutomation is going away in the next major Xcode release.
> https://github.com/facebook/WebDriverAgent/issues/7#issuecomment-140745640

The old UI Automation support in Instruments is deprecated. UI testing in XCTest is the replacement, and where our efforts will be focused going forward.
https://forums.developer.apple.com/thread/9169
> https://github.com/facebook/WebDriverAgent/issues/7#issuecomment-140747097

リンク先のフォーラム

Screen Shot 2015-09-16 at 23.16.49

つまり、次のmajor version upで既存のUIAutomationは除かれ、完全にXCUITestが本流になる、という感じですね。

EspressoやXCUITest含め、このレベルでのテストコードの言語がだんだんとプロダクトコードの言語によるのは別に良いのですが、テストシナリオとテストコードの分離が難しくなって、それらが実装コードの可読性などに引きずられるのは少し面倒だなと感じました。シナリオコード書くの、SwiftやJUnit(Android)だと結構面倒なのですよね。

AppiumやKIFなどのような、なんらかの形でUIAutomationを介しているツールは、すべてXCUITestベースに置き換える必要がありますね。一方で、UIAutomationはAccessibilityの一部として提供されていた面もあるので、XCUITestのほかにもそういったAccessibilityへのアクセス手段でてくるのかな。

どのみち、XCUITestはちゃんと学ぶ必要ありそう。

Android端末の特定パッケージが使う資源を可視化する単純なライブラリを作った

AndroidのCPUリソースやメモリリソースを可視化するために、以下のような簡単なライブラリを作りました。

すみません。Java系ではなくRubyスクリプトです。

https://github.com/KazuCocoa/droid-monitor

単に、

  • cpuinfomeminfoを整形してjsonファイルとして書き出す
  • Google APIを使ってグラフ化する形式にファイルを整形する
  • 簡単なテンプレートHTMLを生成する

ということだけを行っている小さなものです。こういう可視化するツール、手軽に使えるものがなかったので用意してみました。以外と開発者はここらへん気にしないのですかね??

adbコマンドの dumpsys を使うので、Androidのバージョン関わらず値を取得することができます。meminfo に関しては、API Level 18を境に取得可能な形式が変わっているので、ライブラリ側でAPIバージョンを見て対応フォーマットを判断してます。
以下のような感じ。

CPU

Screen Shot 2015-05-23 at 19.46.08

Memory

Screen Shot 2015-05-23 at 19.56.41

使い方

https://github.com/KazuCocoa/droid-monitor/tree/master/sample

に2種類用意したのでそれを見るのが早そう。

こういうときに使う

例えば、Appiumなどを使って常に同じシナリオで、開発周期ごとのリリース物のCPU使用率を計測します。それにより、突然資源の使い方が激しくなったときを検出しやすくします。

あと、adbコマンドを使うだけなので、初期化時の引数にadb devicesなどで得られる端末のシリアル番号を指定してあげると、特定の端末のみをターゲットにすることができます。

締め

adbコマンド、いろいろあって便利。モニタリング用のAPKアプリを作って常駐させておくのも良いのですが、adbコマンドがいろいろ便利なので計測対象の端末に何も手を加えずに資源を可視化できるほうがお得感ありますね。

Stethoを使ってAndroidアプリのデバッグを容易にする

Android、iOSのようなクライアントアプリの開発では、特にDB関連や通信環境が絡むデバッグが面倒です。実際にデバッグを行うとき、例えば、Proxyサーバを立てて通信を覗いたり、SQLiteのファイルを直接覗いたりしますね。はたまた、Logの出力を仕込んで、そのログを追うという方法をとることが多いです。

また、単純な通信量であればAndroid Device Monitorなどが使えますが、通信の中身までは見れません。

それらの壁を低くするツールとして、SquareのGitHubから得られるPony Debuggerが有名です。これは、Chrome Developer Tools を使い、通信の内容を簡単に観察したりできるツールです。また、Android/iOSのChromeブラウザであれば、同様にChrome Developer Tools を使い端末上で動作するブラウザの情報を得ることができます。

そして最近、Facebookが出したAndroid向けのStethoを見つけました。リポジトリを見てみると、最初のコミットが2015年1月30日と非常に若いです。これを組み込んだapkではChrome Developer Tools を介し、SQLiteやNetworkの中身を観察することができます。特別なProxyを用意したり、SQLiteのファイルを直接操作する必要もありません。

まだ若いので、使い方とか諸々変わりそうなのでリンクだけ貼っておきます。

基本的には、Applicationを継承したクラスをonCreateするときに、合わせて初期化メソッドを追加するだけ。
ネットワークをChromeで見るには少し手間かけますが、Squareのokhttpを通信向けパッケージとして使っている場合、OkHttpClientを初期化するときにデバッグ設定を追加するだけという手軽さ。

これらの機能を、例えばBuildConfig.DEBUGのときだけ有効にするとかしておけば、社内で配布するapkは誰もがChromeさえあれば通信内容を確認するという環境が作れてすごく良さそう。

なお、logcatに以下のようなsocketに接続できたという出力が得られたらネットワークの通信もChrome上で見ることができる状態になります。

Connected to the target VM, address: 'localhost:8600', transport: 'socket'

Chromeを経由してネットワークの中身を見るとこんな感じ。

Screen_Shot_2015-03-07_at_11_19_21

Spring Cloud Netflixを読んだ

Springが、Netflixが公開している彼らのOSS群を説明している記事を読みました。ちょっと、記憶に止めておきたい内容を探っているのでそのメモがてら。

記事: http://cloud.spring.io/spring-cloud-netflix/spring-cloud-netflix.html

これは、Netflixのmicroservicesを構成するツール群を説明していました。

  • Service Discovery
    • Eureka Clients
  • Circuit Breaker
    • Hystrix
  • Intelligent Routing
    • Zuul
  • Client Side Load Balancing
    • Ribbon

Service Discovery: Eureka Clients

  • Service Discoveryはmicsoservicesベースのアーキテクチャとして大事な要素

Circuit Breaker

Hystrix Clients

  • Netflixは、CircuitBreakerを実装したもの。Microservicesでは、複数のサービスコールのレイヤを持っている。

  • 低レベルのサービス障害が発生すると、障害がユーザまで伝っていくので、障害のあったサービスをフォールバックすることで障害の伝搬を抑制することが目的

  • ↑の状態になるサービスは、例えば /health の応答として “CIRCUIT_OPEN”というstatusを返す

Dashboard

  • circuitがOpenかCloseかを知ったり、応答速度を監視するためのダッシュボードですね

Turbin

  • すべての /hystrix.stream エンドポイントを、Dashboardの /turbin.streadm エンドポイントに統合するアプリケーション。アプリのインスタンスはEurekaにある。

Declarative REST Client

Feign

  • Feignは、Web serviceクライアント

この記事では、Spring frameworkとして使える方法も紹介してました。

Client Side Load Balancer

Ribbon

  • クライアント側でのロードバランサ。HTTP、TCPベース。
  • Feignは常にRibbonを使うようになっている。

External Configuration

Archaius

  • クライアント側の設定ライブラリ
  • NetflixのすべてのOSSコンポーネントの設定で使われているらしい

Router and Filter

Zuul

  • microservice architectureにおけるサービスのルーティングを行う
  • JVMベースの、ルーティング + サーバ側ロードバランサを備えたライブラリ
  • 以下の機能を提供する
    • Authentication
    • Insights
    • Stress Testing
    • Canary Testing
    • Dynamic Routing
    • Service Migration
    • Load Shedding
    • Security
    • Static Response handling
    • Active/Active traffic management

以上。

Microservicesは基盤技術やツールや体制が充実していないと破綻することがよく言われるようになりました。今回のツール群をみるだけでも、保守や不具合解析以外にも、サービス間のつながりをどうするかとか、障害発生時もサービス全体として正しく振る舞うにはとか、そういう設計も重要な位置を占めていることが容易に想像できます。

事業に対するシステム構成上、Monolithicで十分であればそれに越したことは無いですね。。。

Mockサーバ比較とWireMockメモ

少し前から、モバイルアプリケーションに対してHermetic testと呼ばれる類のテストタイプを実施できる環境を整え始めました。その中で、JSONで記述したHTTPレスポンスを返すだけのような、簡単なMockServerを探していました。

なければ簡単なものを作ろうとも思ったのですが、結構期待していたものがあったので、メモ。

調べたもの

あたり。他にもありましたが、ざっと見て次〜としていた。

Continue reading “Mockサーバ比較とWireMockメモ”

QuickLookPluginsのインストール

MacのQuickLookにてJsonなどのフォーマットを閲覧可能にするために便利なものがあったのでメモ

$ brew install caskroom/cask/brew-cask
$ brew cask install qlcolorcode qlstephen qlmarkdown quicklook-json qlprettypatch quicklook-csv betterzipql webp-quicklook suspicious-package