テストコードの品質を客観的な数値で担保しよう〜Mutation Testのすすめ〜

YAPC::Hakodate 2024 での登壇資料です。
https://fortee.jp/yapc-hakodate-2024/proposal/a91375cf-5d1c-4abf-bedf-b291c685e056

Transcript

1. Kanon (@ysknsid25) #yapcjapan テストコードの品質を 客観的な数値で担保しよう 〜 Mutation Testのすすめ 〜
2. README @ysknsid25 水瀬いのりさん が推し 表紙のアイコンは公式配布のものです。 https://x.com/tonikakuhayate/status/1806583319951233034?s=46&t=zwt7nxAvhST7_30NZnyMTQ
3. この発表のゴール 3 • Mutation Testについて知っていただく • 「Mutation Testを試しにやってみようかな」と思ってい ただく
4. 4 Mutation Testとは？
5. コードに意図的なバグを植え付けることで、 テストコードの検証が適切に行われているか？ を測定する手法 5 Mutation Testとは？
6. 6 自分が自動テストに対してずっと思ってたこと Mutation Testとは？ テストコードがほんまに正しく書けてるか分からんのに、 テストコードを書いて「カバレッジx%やからヨシ！」 でほんまに品質って担保できてるんか？
7. 7 カバレッジレポートの罠 Mutation Testとは？ • 通常のカバレッジメトリクスは嘘をつく • 例えば以下の(極端なテストケース)など コードサンプル javascript-testing-best-practice
8. 8 そこで登場するのが Mutation Test Mutation Testとは？ • Mutation = (突然) 変異 ◦ コードを意図的に変更し、バグを植え付ける ◦ ex) a===0 を a !== 0 と変異させる ◦ その後テストを実行し、正しいテストが書かれていなければアサーションが エラーとなるはず ◦ エラーとならなかった箇所がきちんと検証されていないと判断できる • Googleでは2017~18年ごろから全社的に導入されているっぽい 参考：Googleにおける突然変異テストの状況 変異の内容と種類
9. 9 Mutation Test に関わる指標 Mutation Testとは？ • Killed ◦ 変異後、成功すべきテストが失敗したことにより検知された変異の数 • Survived ◦ 変異後、失敗すべきテストが成功したことにより検知された変異の数 つまり、Survivedの数が多ければ多いほどテストコードの品質が低い
10. 10 Mutation Test に関わる指標 Mutation Testとは？ Mutation Score = Killed / Total * 100 この割合が高いほど品質がよい
11. 11 百聞は一見に如かず
12. 12 Stryker を使っていろいろと見てみます 解像度を上げていく • Mutation ライブラリ • 変異を自動で作ったり、レポート作ったり • 対応言語 ◦ JS ◦ C# ◦ Scala Playground (C#) があるのでそれを使ってみる
13. 13 Mutation Reportを見てみる 解像度を上げていく
14. 14 “失敗すべきテストが成功するとは？” 解像度を上げていく これを覚えておい てください これを覚えておい てください
15. 15 “失敗すべきテストが成功するとは？” 解像度を上げていく
16. 16 “失敗すべきテストが成功するとは？” 解像度を上げていく 変異前も前後も 結果は100 =変異してるのに テストは成功する この場合は 引数が適切でない
17. 17 適切なテストにするには？ 解像度を上げていく テストパラメータを 修正し、再実行
18. 18 LGTM👍 解像度を上げていく スコアアップ 🎉 Survivedだった 変異が消えた
19. 19 実際に導入して困ったこと
20. 20 今回の導入環境など • Nest.js (v10.4.1) ◦ TypeScript (v5.5.4) ◦ node (v20.11.0) ◦ Vitest (v2.0.5) ◦ Stryker (v8.5.0) • マシンはMBA M2 16GB • 新規プロジェクトに導入
21. 21 余談: TypeScript でも Strykerは変異を起こしてくれる レポートを見た感じ TSに対して変異を作っている 設定は特にしてない
22. 22 実戦で困ったこと • 正攻法で実行すると死ぬほど遅い • Stryker Dashboardがプライベートリポジトリだと使えない
23. 23 正攻法で実行すると死ぬほど遅い 実戦で困ったこと CIに入れられるわけない Unit テストは 2,30秒くらいで終わっ てる
24. 24 なぜ遅いのか？ • 変異の数はこの式で決まる ◦ 変異発生対象ファイル × 変異の種類 • 全体の実行時間はこの式で決まる ◦ 変異の数 × Unitテストケースの実行時間 • Strykerのデフォルト設定 ◦ 全てのファイル × 全変異パターン • よって変異発生対象ファイルと変異の種類を絞って あげればいい 正攻法で実行すると死ぬほど遅い 変異発生対象ファイルを指定 除外する変異発生対象を指定
25. 25 そう簡単に改善ｻｾﾈｰﾖ ★ 正攻法で実行すると死ぬほど遅い CIに (ry
26. 26 実行時間で困った時の解法: 差分実行を使う • incremental オプション ◦ incremental: true で設定 ◦ jsonで前回の結果を保存 ◦ 変異対象のファイルに差分があった箇所のみ新たに(再度)変異を発生させ て実行 正攻法で実行すると死ぬほど遅い
27. 27 LGTM👍 正攻法で実行すると死ぬほど遅い ただ、変更箇所が多いと 実行時間は比例する が、PRを小さくするという意識を チームに植え付けられたので 結果オーライ
28. 28 Stryker Dashboardがプライベートリポジトリに使えない 実戦で困ったこと • やろうとしていたこと ◦ GHAでMutation Testを定期実行して、レポートを取得 ▪ Mutation Scoreがキープできているか？ ▪ Mutation Scoreをより高くしていくために、どこを直す必要があるか？ • なぜ？ ◦ チームメンバーの品質への意識の向上 ◦ 修正を未経験新入社員にやってもらうことでプロダクションに影響のないところでコー ディング経験を積んでもらえる
29. 29 Google Cloud Storageへ送信 + Slack通知 • Workload Identity連携でGCSへ送信 • バケットのURLをSlack通知 • バケットは非公開&権限付与されたアカウントのみ 閲覧可能な設定 • GCSに置いたレポートはライフサイクル管理を設定 することで、一定期間が過ぎたものは削除される Stryker Dashboardがプライベートリポジトリで使えない
30. 30 LGTM👍 Stryker Dashboardがプライベートリポジトリで使えない 推しに通知してもらえて wktk
31. 31 導入した結果、どうなったか？
32. 32 Unitテストのカバレッジ • 一般的には65% ~ 80%くらいを目指すのが良いくらいとされるなか、かなり高い数値を キープできている (2024/09/29現在) • Mutation Testがあるおかげで、ある程度この数値も信頼できるようになった • 特に無理してテストを書いている感じはない • そもそも全体のStatementsは1805程度なので比較的小さい 導入した結果、どうなったか？
33. 33 Mutation テストのカバレッジ • こっちは77%くらいなのでまずまず • Strykerにも閾値を設定できて(thresholdオプション)、今は50%以上なら CIはコケないようにしている 導入した結果、どうなったか？
34. 34 その他感想 • 品質への意識が高まっただけでなく、結果的にPRを小さくする文化が浸透し たのはよかった • 今回は小さめのプロジェクトに導入したおかげでわりかし早く実行できている が、大規模なプロジェクトに後から入れるのはしんどそう ◦ 入れる場合、変異対象や種類を部分的に入れて、徐々に拡張していくの がよさそう • CIのタイミングでは「どこがSuvivedしているか？」を知ることができない 導入した結果、どうなったか？
35. 35 PHPのMutationライブラリ・Infection にはそれがある CIのタイミングでは「どこがSuvivedしているか？」を知ることができない
36. 36 自動テスト・品質向上の一助になれば幸いです
37. 37 ご清聴、あざざました
38. 38 📢 おわりに宣伝 🙏 オフラインLT会を 神戸で開催してます！ TS＋周辺技術 Figma、npmなどなど 範囲が広いので登壇しやすい！