Android Test Night #5 - Androidテスト全書の回 - に参加してきた
大変有意義な会だったので、思わず久しぶりにblogを書きます。
トークでも懇親会でも「あるある」という共感が多くて面白かったです。
テストデータの話
最近Google Maps Platformを使っていて、そのテストがしづらいのをつぶやいたところ質問で拾っていただきました。
で、その回答からの気付きと、その後の懇親会などで知ったこと。
わりとみんな同じ問題を抱えてて、本番データ持ってくる君、フォーム自動入力する君、データ偽装する君など、独自に作ってるという話が聞けた #android_test_night
— ゐろは@技術書典応援祭 (@wiroha) 2018年11月30日
本の内容は読んでて知ってるんですが、あまり自動/手動を区別して考えてなかったので、そういえばと気付きを得ました。
本番データを持ってくる話は、クックパッドさんのこちらです。だいぶ前の記事ですが、当時話題になりましたね。
techlife.cookpad.com
今うちではGCPを使ってるのですが、同じように出来るのかな…
ただうちの場合、本番データを丸々持ってくるのは少々オーバースペック感もあります。
以前の職場では、自動テスト用に、yamlでデータを定義すると適切な型・形式になって返ってくる仕組みがありました。
あれをAndroidの実装中も使いたい気持ちになります。（当時はバックエンド書いてたので色々話は違いそう）
Kotlinだと「ちょっとここのデータだけ書き換えて確認したいな」と思っても「それvalやで」と出来なかったりするので…
自動・手動の良いところを組み合わせて効率化できないかなー
Google Play Consoleに組み込まれているテスト
「今はFirebase Test LabがGoogle Play Consoleにも組み込まれてますよね」という話題が出ました。
これのことですね。リリース前レポート、いろんな画面のキャプチャも撮っておいてくれたりして、
「あのバージョンのあの画面って、どんな仕様だったっけ？」と振り返りたいときに便利そうだなぁと思っています。
ログイン認証情報を設定する を使うと要ログインな画面もテストされます。どんどん高機能化しててすごい。
ただ、リリース版のapkで実行されるので不安だなー、と思ったら後で懇親会で教えてもらいました。
これ、自動テストかどうかを取得出来るので、それによって保存しないとか処理を分けると避けられるらしい
— ゐろは@技術書典応援祭 (@wiroha) 2018年11月30日
なるほどー！と思ったものの、よくよく考えてみると実行して良い処理・良くない処理を分けていくのも大変なので、
やはりちゃんとFirebase TestLabを使ってQA環境で動かした方が良いんだろうなぁ。
良さを実感出来るという意味では、Play Consoleに組み込まれてるのは良いですね。
QAを楽にしたい
手動テストの課題でパッと思いついたテストデータの用意の話だったんですが、他にも色々あるよなーと思ってます。
- テストケース・QA結果のわかりやすいまとめ方
- 現状、普通にspreadsheetにまとめている。横スクロールがめっちゃ長くなりがちじゃないですか？専用ツールがあって良い。
- iOSと簡単に見比べたい
- 仕様の管理
- QAというか実装中もぶつかる問題なのですが、「最終的な理想の仕様」と「今回のバージョンではここまでやる」仕様がよくわからなくなります。
他にもいろいろありそう。うちはこんなツール使ってるよ！とかあれば知りたいです。
本読んでテスト書いてます！
質問のときにそんな声が出てましたが、自分も読んでテスト書いてます！
まだごく一部しかないので増やしていきたいです。
それは自動化して楽にする目的もありますし、どういう設計がテスタブルなのか学びたいという目的も大きいです。
懇親会で著者の皆さまにサインをもらいました！
本にサインがあると、著者の皆さまの力をしっかり吸収するぞ！という意欲がわいてくるのでおすすめです。
査読に協力させていただいたおかげで、関係者の皆さまが自分のことを知ってくださっていたのも嬉しかったです。
もう買っている方が多いと思いますが、本の紹介リンクも貼っておきますね！
peaks.cc
今年Androidエンジニアに転職した初心者の自分にはまさにピッタリの本で、良いタイミングに感謝しかありません。
会でも編集力を絶賛されていた @mhidaka さんに日常的に詳細の解説をしてもらえたり、本当に恵まれた環境にいるのでたくさん活かしていきます！
著者の皆さま、執筆本当にお疲れさまでした！！
