Android Test Night #5 Androidテスト全書の回に行ってきました #android_test_night

11月に一般販売が始まった『Androidテスト全書』の著者さん達によるトーク回ということで、年甲斐もなく「ブログ・Qiita枠」で申し込んで参加してきました。

testnight.connpass.com

『Androidテスト全書』は、技術書クラウドファンディングのPEAKSで企画・制作されたAndroidアプリのテスト自動化を中心とした書籍で、11月初旬より製本版の一般販売が開始され、15日で限定セール分が完売してしまったという人気の書籍です。セールは終わっていますが、製本版・電子版とも下記ページから購入できます。

Androidテスト全書

著者：白山文彦,外山純生,平田敏之,菊池紘,堀江亮介,
製本版,電子版
PEAKSで購入する

本書はざっと通読しており、特に以下の観点でおすすめできる書籍です。

自動テストの書き方にとどまらず、なぜテストを書くべきなのかといった、「手段」から一歩引いたところから丁寧に書かれている
JUnit、Mockitoといった基本的なテスティングフレームワークによる基本的なテストの書きかただけでなく、非同期、RxJavaなどに対するテストの書きかたも押さえられている
UIテストに関して、Espresso、Appiumそれぞれにページが割かれ、差別化されている
CI/CDの導入も丁寧にかかれており、Firebase Test Labにも言及されている
JUnit 5への移行、Local Unit TestとInstrumentation Testの統合（Jetpackへの統合）など、少し先にこうなっていくという事項にも言及されている

トークセッション

本会は、SFにいる白山さん（冒頭にビデオレターで登場）以外の著者の方々と、編集の日高さんによるトークで進行されました。

著者のおすすめポイント

堀江さん：ツールの使い方とかでなく、CI/CDとは、というところから書いた
菊池さん：公式にはまだJUnit 4なのに、JUnit 5を動かせるのが楽しい。個人的にそうゆうのが好きなので紹介した。Parameterized Testは便利で使える。この分量が大きくなってしまって章立てを変えた
平田さん：Appiumまわりは、本書のために会社でUIテストやりたい人を募って実際に導入した成果を書いている。さらっと書いてるところも実際は大変だったりした
外山さん：UIテスト導入まわりでは、『システムテスト自動化標準ガイド』（通称「ギア本」）から、最低限押さえておいてほしい点のピックアップもしている。Espressoに関しては、ドキュメントからだけではわからないところもソースを読んだり試したりした結果を書いてある

システムテスト自動化標準ガイド CodeZine BOOKS

作者: Mark Fewster,Dorothy Graham
出版社/メーカー: 翔泳社
発売日: 2014/12/17
メディア: Kindle版
この商品を含むブログ (3件) を見る

苦労したところ

菊池さん：本が出たあと、Gradle JUnit Pluginの変更がどんどん入ってつらい。ただ、本書の記載内容が使えなくなったわけでなく、便利なアノテーションとかが追加された等。執筆期間にGoogle I/O 2018を挟んだので不安だったが、大きな変更はなく安心した
堀江さん：仕事との兼ね合い、子育てもあるので時間がつらかった
平田さん：執筆中にAppiumのバージョンアップ（1.8 -> 1.9）、uiautomator2 driverのBetaが取れたのはよかった
外山さん：Kotlinを使うかどうか悩んだ。執筆当初はコンパイルが通らないところがあり、Javaで書いた。電書版直前くらいに試したらKotlinもコンパイルが通るようになっていた
日高さん：読むターゲットの選定。初心者なのかバリバリやってる方か。テストのことをちゃんと伝えたい、わかりやすく書きたい。改訂版の予定はまだないが、売上がよかったらぜひやりたい

PEAKSについて

PEAKSで書いた書籍を技術書典で売るときにTシャツを作ってもらえた
表紙はなぜこうなったのか？
- 永野さん@PEAKS：わからない
永野さん@PEAKS：本書は、他の本に比べてクロスレビューが活発だった

自分以外のセクションでおすすめ

外山さん：非同期テスト細かく書いてある、CI/CDとかあまり詳しくなかったので勉強になった
平田さん：自身がiOS寄りなので、4・5章が特に、視点が違って面白かった
菊池さん：2年くらい前、AppiumでAndroid 4系をテストしようとして辛かったのが、今はよくなってること。Circle CIのManual Approvalsで手動でワークフローのトリガを設定できること
堀江さん：1章、テストをなぜ書くのかなど
日高さん：企画段階では250ページ、完成400ページ。これでも削ったところもある。技術の変化が早いので古臭くならないようにした。例えばインストール手順のようなWebで得られるところは割愛している。深夜2時に原稿があがって、その時間から相互レビューがはじまるくらい皆書いていた。編集者は、毎回、頭をリフレッシュして読み直すのが仕事

日高さんの編集について

堀江さん：編集前160ページのセクションが60ページくらいに減った
菊池さん：そこまで減らなかったけど、ごっそり入れ替えとかの指示があると、そこからの辻褄合わせとか大変だった。趣味で小説書いたりしてたので、細かい言い回し等には気を使うほうなるので、その辺りの指摘はそのままにしたところも
平田さん：社内でUIテストを導入しつつ書いたので混乱した部分もあったが、羊さんがヒカリエまで来て話したりした。指摘箇所に理由をつけてくれるので納得感がある
外山さん：著者脱稿して80%くらいの完成度と思っていたら、その後が大変だった。でも読みやすくはなってた。抽象的でなく具体的に書くべき、みたいな指摘とか

普段どこに気をつけてテストしているか

平田さん：QAがやってることを自動にできないかと相談されるが、マニュアルテストをそのまま自動化することは運用まで考えるとROIが良くないので、そこから話す
- UIテストの安定性。CIに乗せると落ちたり
- どこまで自動化するか
外山さん：課金などのシステムが出すDialog、テストはできるけどGoogle都合で変わるので大変だけど、大事なので押さえたいところ
堀江さん：CI/CDで、自動と手動をひとつのフローに乗せるべきか。Circle CIでは手動テストの完了をトリガにワークフローを進めてリリースりたりできるので活用している
- ZOZOにもSWET(SoftWare Engineer in Test)のような組織はあってUIテストは書いてるけど、CI/CDに統合はされていない
- 手動テストの人がちゃんと探索的テストに注力できるようなフローにする
菊池さん：エンジニア自体が少ないので、UIテストには工数をかけられていない。コストとのバランス

テストを書いたコストがペイしたと思った経験

平田さん：自動テストでバグを見つけるのはよくない*1。テストがある安心感と、正しく動いていることが確認できることが良い。安心してリリースできるのが大事。テストが落ちるのは環境的な問題が多い

現場で実現するために大事なこと、チームプレー

外山さん：自動テストは銀の弾丸ではないので、Unit/UIテストの仕切りが大事。QAが「全部自動化してほしい」と言ってくることもあるが、認識合わせが大変
- 日高さん：そのときのキーワードは工数？
- 外山さん：工数だけではなく、Unitでやるべきだけど構造上できないのでUIでやったり、事情を汲んでいる
堀江さん：CI/CDがないところに途中から導入したとき。困っていないか聞いて回って、SDKバージョンを上げるのを躊躇するみたいな話を聞く。テストをたくさん書くより、効果的なところから導入していくようにしている

ライブラリ等のバージョンを上げていくか

菊池さん：ライブラリ全般、無理にバージョンを上げる必要はないと思っている
外山さん：テスト系ライブラリはわりとカジュアルに上げる

会場からの質問

QAがテストを書くのか

外山さん：そうしたいが、まだできていない。Excelにシナリオを書けばテスト実行できるくらいにしたいけど、それを作るとコストが見合わないのでできていない
堀江さん：会社に受け入れテストを自動化している部隊がいたが、最近まで知らなかったし、経緯もよくわからない。今後連携していく

テストを書くタイミングについて

テストファーストだと仕様変更で書き直しになる。完成してから書くべきなのか？

変わらないところを中心に書くのがいいのでは。永続化まわりとか
UIのほうはあとまわしにして、Unit Testはテストファーストで書く

GUIでテストを作れるツールについて

日本に限らず、増えてきてはいる。どのように使うかによっては使えると思うので、徐々に使えるとは思っている。精度次第？
Firebase Test LabのRobo testは、だんだんかしこくなってる。単純なアクティビティ遷移でクラッシュみたいなのは検出してくれる

テストピラミッドの各層でしかできない検証について

Unit Testから入って、CIを導入してから、UIテストにかかればいいのでは。CIは入れるべき

プロダクションのライブラリやSDKバージョンを上げることについて

ライブラリやSDKのバージョンを上げるという話があったが、そのときに問題を検出できるように考慮したテストの書き方はありますか？

特にその目的で考慮していることはない
Firebase SDKを上げたときにビルド失敗はあった。レポートを社内に展開したりはした
ライブラリのバージョンは、上げてもすぐ元が消えるとかある

テストコードの保守性・可読性

本質的でない部分が多くなったり、そもそも何をテストしたかったのかわからなかったりする。工夫はあるか

チームが日本人メインであれば、テストメソッドの名前を日本語にすることは有効
- Instrumentation testのほうは日本語使えない
前設定のコードが多くなるのであれば、Mockitoとかのライブラリを使って簡潔に書けるようにする
テストコードの中を、Setup, Exercise, Verify, Teardownにちゃんと分けて、メソッド抽出したりもする。仕様変更などでSetupがごっそり変わることもあるが、分けられていれば対応も容易になる

註：このあたりの用語は、『xUnit Test Patterns』から。テストダブル（Mock等）のパターンも参考になります。