はじめに
1月に入社したアプリチームの工藤です。
DeNA SWETグループの平田さんをお招きして、社内で第5回目のテスト勉強会を開催しました。この記事はそのレポートになります。
オクトでは定期的に社内勉強会を開催しています。
Vue.js勉強会や↓ tech.88oct.co.jp
SQL勉強会なども↓ tech.88oct.co.jp
今回は前回の反省を踏まえ、畳の小上がりスペースで行いました。
20名ほどの社員が真剣に耳をかたむけていて、雰囲気と場所のギャップが新鮮でした1。
以前のテスト勉強会はこちら↓ tech.88oct.co.jp
内容
前半はユニットテストで重要な考え方であるFirst2とA-Rtip3に共通して挙げられている独立性・再現性について、後半は保守性の高いテストの設計について説明いただきました。
独立性
テストが増えるにつれ実行速度が課題になります。
改善するためには並列で稼働させる必要がありますが、テスト同士に依存関係がなく独立した状態でないといけません。
これはテストをランダム実行することでチェックできますが、使える環境と使えない環境があるので注意が必要とのことです。
再現性
CI環境は常に動くことが重要です。
たまに失敗したり再実行すれば成功するテストを放置していた結果、自動テストが信用されなくなってしまった現場を以前見たことがあり、この部分は当時を思い出しながら聞いていました。
再現性の低下に対処するには、可能性があるものをどれだけ知っているか?がカギになるそうです。
保守性について
テストコードが徐々に負債になるというのはあまり意識したことがなく、非常に勉強になりました。
レガシー化した部分の改善を容易にするためにも、シンプルなテストコードを意識するのが重要とのことです。
書き方の参考として、 AAA・Four-Phase Testというパターンを紹介いただきました。
質問タイム(特に印象に残ったもの)
Q. テストケース名に日本語を使うか?
A 無理に英語にする必要はないが、日本語はプラットフォームや環境によっては正しく実行できないことがあるので確認してから使う。
※AndroidではJunit5からは @DisplayName が使えるので活用すると良いと後から教えていただきました。
Q. 既存コードに対するテスト追加とテストのためのリファクタリングはどちらを優先すべきか
A リファクタすべきという危険を感じ取ったら(スライドの表現を使って匂いと表現されてました)、まずはリファクタリングすべき。
リファクタ前に無理やりテストコードを書いたとしても、リファクタ後にそれが負債になってしまう。
最後に
テストカバレッジなどは元々知識として知っていたものの、テストコードの保守性のために設計が必要という事に気づけたのが良かったです。 今はモバイルアプリのCD/CI環境整備を進めていて、自動テストのコードも徐々に増えてきています。
私も早くテストコードの匂いを感じ取れるように成長していきたいです。
こちらのサイトもよろしくおねがいします!
