11月に一般販売が始まった『Androidテスト全書』の著者さん達によるトーク回ということで、年甲斐もなく「ブログ・Qiita枠」で申し込んで参加してきました。
『Androidテスト全書』は、技術書クラウドファンディングのPEAKSで企画・制作されたAndroidアプリのテスト自動化を中心とした書籍で、11月初旬より製本版の一般販売が開始され、15日で限定セール分が完売してしまったという人気の書籍です。 セールは終わっていますが、製本版・電子版とも下記ページから購入できます。
本書はざっと通読しており、特に以下の観点でおすすめできる書籍です。
- 自動テストの書き方にとどまらず、なぜテストを書くべきなのかといった、「手段」から一歩引いたところから丁寧に書かれている
- 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が「全部自動化してほしい」と言ってくることもあるが、認識合わせが大変
- 堀江さん：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等）のパターンも参考になります。
xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))
- 作者: Gerard Meszaros
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 2007/05/21
- メディア: ハードカバー
- 購入: 5人 クリック: 210回
- この商品を含むブログ (66件) を見る
テストのリファクタリングに使う時間はトータル何%？
- 共通化をするくらいで、そう多くはない
(AACの)Repositoryのテストについて
Mockを使うUnit Testでは仕様変更の対応が不安。Repositoryまで統合したテストもするべきか
- OkHttpのMockWebServerを使った統合テストは有効
- Swaggerとか使ってモックサーバを立てる
既存プロジェクトに対してテストをどう書くか
- データ層から進めていく
- セオリーだと、Integration Testなど外側からテストを書いて保護していくが、これは大変。一部アーキテクチャを組み替えながら進められるのであれば、それがいいと思う
所感
会場で質問をされた方の中に「本書を読んでテストを書き始めた」という方もいました。それだけの力のある本が、いい時期に*2書かれたのではないかと思います。
今回のトークセッションでは、著者および編集者の皆さんの熱量（本書に対するものと、テストに対するものの両方）を感じ取ることができ、また共著の大変さを思い出し、改めてじっくり再読しなければ、という気持ちになりました。
本書が広く読まれて（売れて）、改版や、また他分野のテストに関する書籍の出版につながるといいな、と思います。そして、テストを書いてCI/CDすることが当然という世の中が早く来てほしい。
ともかく、著者・編集者、ほか関係者の皆さん、お疲れさまでした。ありがとうございました。
