Androidテスト全書が発売されましたね！

とてもめでたい。

私はアーリーアクセスの段階で野次馬のようにいくつかコメントさせていただいたりしました。また、推薦コメントとしてトップにも記載していただいて、大変ありがとうございます。

個人的には、このような書籍が私の学び始めの頃にあればとても知の高速道路を走れたのでは感が満載のものだと感じます。”テスト”という一言で丸っと全体を包むのではなく、いくつかレイヤーも分けつつ分解しているのもとても良いですよね。様々なレイヤーで目的に合わせながらテストの実行環境が整っていく（であろう）これからの市場ですが、それらを利用するにあたり基礎となるものだと感じています。

なおここでいう”テスト”は、一律、開発者テストやテストエンジニアによりテストコードを書いていくという範囲での話に焦点を当てます。

2, 3章

多くは実装やアーキテクチャに依存することも多い話ですね。この書籍では、巷でみる（最近）よく使われるライブラリを使ったテストの書き方のほか、テストタブルの考え方まで踏み込んだ箇所があります。そのため、単なるツールの使い方ではなく、その必要性や用途などまで学ぶことができるのではないでしょうか。それらはAndroidというものに限らないところも多いので、iOSやそのほかのWeb系の話に流れたとしても、転用のきく知識となるかと思います。

ここはコードも多く出るので、読みながら写経しながら進めることが一番良いと感じています。

4, 5, 6章

UIテストのEspresso, Appiumを使った話。

これら、結構比較構造で紹介される場面も見ますね。同じ”UIテスト”という言葉として。ただ、多少はカバーする分野がかぶってますが、私は全く対立するものではないと思っています。（Appium自体、Espresso/uiautomator2を経由して色々とした操作を実現していますし。）

そこらへんも説明されたり、具体的な実装の話まで踏み込まれています。

最近だと AppiumのAIによる要素セレクタを試してみたら、自動テストの未来を感じた でも取り上げられましたが、Appiumをモバイルアプリ操作のフレームワークとしてツール群の間に挟むことで、それよりも上のレイヤで様々な取り組みを実施できるなどもあります。これもEspressoだけを中心とした形式で、test.ai のような企業が独立して取り組むには難しい面もありますね。

Espressoの方がとても良い場面も多くあります。そのため、私は Test automation design for Cookpad’s global Android app というブログを、クックパッドの海外事業部のページに投稿しました。そこでは、EspressoもAppiumも(後者は将来的に、ですが)使う流れを載せています。

適材適所で使おう、という話ですね。個人的な日本・世界での活動をベースにすると、両方を行き来できる人は非常に限られていて、そういう人がいる組織は方針の選択など含めてとても強いのだと感じました。私が見た世界の中では、純粋なAndroid開発者だけしかいない（開発者人数も限られている）ところは大体はEspressoですが、Test/QAエンジニアをもつところは大体はAppiumを利用しているようです。その両方を行き来できる人は選択しているぽいです。ただ、Agodaのように色々と判断を倒しているようなところもいくつかあるようですね。

いずれも、Espressoを使うところは単機能(or 1つのView)における実装の確実さを担保していきたいというモチベーションが大きいように思えます。私たちもそんな感じでした。ユーザのシナリオや、実環境に近しいところを対象にしようとしたらAppiumの比率が高くなるという感じでしょう。HeadSpinのように、物理的にもよりユーザに近しいところのテストを世界各国で実施できる環境では、Appiumの方が多数のようです。

7章

JUnit5の話ですね！私もいくつか触ったことがありますが、まだJUnit5を少なくとも10人以上でガシガシ開発しているような組織にはほいそれと導入はできなかったですが。。(JUnit4 のRuleを使ったものもそれなりに持っているプロジェクトですし)

JUnit5のいくつかのアノテーションなどは個人的にも導入して行きたいと思っていたものです。なので、JUnit5が成熟して、Androidの標準ライブラリ周辺でも特に壁なく利用できるところまでいくと良いなと思います。

Jetpackとして丸っとした開発ツールの公式化が進みましたし、その中にJUnit5が入り始めるとガッと世界は進みそうだと感じます。

8章

CI/CD環境はモバイルの場合は特に、最近も頭を抱えますね…CircleCIは鉄板だと思います。OSSでしか触れてはないのですが、最近だと性能改善もだいぶ見られるようですね。

私は、1000件程度のnon-UIテスト、40件行かないくらいのEspressoによるUIテストを実装していたプロジェクトにおいて、lint, 全テストをPush毎に、10分以内で全てを終わらせるためにx3 Speed Up Android CI at Cookpadという構成を取っていました。その結果、多くの場合は6分~7分程度で、テストなど含めて開発のフィードバックサイクルを回せるようにしていました。この書籍でいう、”コミットステージ”でEspressoによるUIテストも含めて完了させていた、という感じです。ただ、その環境はAWS上で動作するJenkin環境でした。

それとは別に、将来的には定期的にUIテストの、ユーザ受け入れレベルのものを実施したいとも思っていました。（が、そこらへんは環境の成熟など含めてまだ手軽ではないですね。。。）これにより、手動テストステージの多くは省ける + パフォーマンス系のあたいもここで取得できる状態には持っていけると思います。

先にも書きましたが、これからは用途に応じたテスト実行環境が成熟していく時期だと思うので、読者の皆様は待っておいてもらえると良さそう。（私はそういうところで少しの間、時間を使うことにしました。）

余談

いくつか私も情報の整理のためにAndroid向けの砂場repository とか、iOS向けの砂場repository とか作りながら情報を追ってたりします。こういう砂場的なところがないと色々と新しい/既存の/改善をトライできないですね。テストツールの文脈でも。

Android Pから実行系の改善によりモックの環境が改善されましたね。

[Android]some mocking features work only on Android P+

セキュリティが少し厳密になったため、例えばアニメーションスケールをテストのために外部から操作したいとなった時には [Android]Relax “Restrictions on non-SDK interfaces” on Android P ,

https://github.com/KazuCocoa/DroidTestHelper#note-for-android-p のように事前にsecurity policyの操作をしたりする必要も出たりしています。気にしないとですね。

なお、Appiumにはすでにコマンドは入れているのであとはそれを使うようにしないとですね…

https://github.com/appium/appium-adb/blob/9fa581d84e1e5aebf44112e5ad05f64ddbb3be8e/lib/tools/adb-commands.js#L353-L377

このような変化もこれからあると思います。ただ、基礎的なコードの記述環境はおそらく大きく変化する頻度は少ないと思います。なので、そういう面でもAndroidテスト全書は読んでおいて損はないかな、という感じ。