大分日が空いてしまいましたが、上記のイベント動画を見た*1ので、感想を書いていこうと思います。
会の概要
以下、Connpassのイベントページから引用です。
多くの開発現場で行われているのと同じように、LAPRASではテストを書きながら開発を進めています。
カバレッジもそこそこを維持しつつ、CIが通っていることを信頼できている状態です。
しかしながら、テスト周りはチームで手探りで進めてきたため、モヤモヤもいくつかあります。「このままで本当に良いのだろうか」「もっと良い方法/状態はあるのでは」という気持ちが強くなってきました。
そこで、テストの構築や運用をより良いものとするために、テスト駆動開発の第一人者であるt_wadaさんに相談する場を頂戴しました。
LAPRASでのテスト周りの現状を元に、t_wadaさんに質問を投げかける形式で実施する勉強会を、せっかくなので収録し、公開しようと思います。皆でテスト周りのモヤモヤを解消して、より良い状態に近づくためのヒントを得られればと思っています。簡単ですが、LAPRASの開発プロセスやテスト事情についても共有します。
会で印象的だったこと
ロールバックの自動化
LAPRAS社ではリリースの自動化を実践されているものの、ロールバックの自動化はまだ実践されていないということで、ロールバックを自動化する意義についてのお話がありました。
プロダクト規模が一定以上になった場合、リリース前に手動でテストをしてプロダクトの品質を担保するということが厳しくなってくるため、自動テストを全てPassするといった条件を満たせていればリリース、という形に自然となります。
しかし、このリリース時の自動テストでは、どうしてもカバーできない部分や本番環境でないと検出できない部分が出てくるため、この時にロールバックの自動化+監視を実現しておくことが大切になるというお話がありました。
ロールバックの自動化というのは、リリースの自動化と比較すると、自分自身でもあまり明確な意義を感じられていなかった部分だったので、twadaさんからの説明を聞くことができて非常に良かったです。
Flaky testの立ち向かい方
Flaky testに立ち向かう第一歩として、テストの履歴をデータとして見れるようにしておくことが重要だというお話がありました。
個別のテスト履歴を見れるようにしておくことで、Flaky testの特定ができるようになり、テストが失敗する傾向や、そもそも本当にFlaky testなのか(テストの書き方がおかしいのか、こけちゃいけないテストがこけているのか...)が分かるというお話でした。
これに関連して、Flaky testにタグをつけておくのも効果的だというお話がありました。
Flaky testにタグをつけておくことで、テストがこけた時に、Flaky testのタグがついているテストは再実行してみて、問題なければリリースするという判断を加えることができるのが、タグをつけておくことが効果的に作用する一例として挙げられていました。
また、基本的にFlaky testは悪であるものの、Flakyさが一概に悪と言えるわけではないというお話もいただくことができました。
例えば、Flakyさが思わぬバグを見つける場合などは、*2Flakyさがいい意味で作用しているというお話を聴くことができました。
冗長なテストケースの削減
冗長なテストケースができる原因としては、どこのテストで何を書くべきかが整理されていないことが、根本的な原因となっている場合が多く、テスト設計レベルの問題とコードレベルの問題の2つに分かれるというということが話題に出ていました。
コードレベルでは、上位レイヤーと下位レイヤーで事後条件が同じものをテストしていることが多いので、このアサーションを共通化することで対処できるという話でした*3
一方、テスト設計レベルでは、テストピラミッドの上位(E2E test)では正常系をメインにテストするようにして、下位(Unit test)ではエラー系や例外系のテストをする、といった仕切りを分けることで、冗長なケースが削除されていくだろうという話がありました。
会全体を通した感想
twadaさんの話を聴くのは実は初めての機会だったのですが、原理原則から丁寧に考え方を説明してくれるので、めちゃくちゃ話が分かりやすくて、目から鱗が落ちる会でした。
自分の現場でも抱えているような問題について議論されている場面も多く、大変参考になる会で、イベント公開してくれたLAPRASさんには心から感謝したいです。
