Mutation Testingを活用して テスト品質を考える /introduction to mutation testing

「ユニットテスト新着トピック３選！イチからわかるイマドキのテスト」での登壇資料です

Transcript

1. 日本の医療体験を、しなやかに。 © KAKEHASHI Inc. Mutation Testingを活用して テスト品質を考える nanko(@yesman_kakuteki) 2024.5.23 @MagicPod
2. © KAKEHASHI Inc. はじめに • テストコードは書いてるけど、その品質をどう評価すればいいかわからな い人 • テストに課題感はあるがどう改善すればいいか悩んでいる人 想定する聞き手
3. © KAKEHASHI Inc. はじめに • テストコードの品質改善をしたくなった時のアイデアが持てる • Mutation Testingがどういうテスト手法かわかる 発表のアウトカム
4. © KAKEHASHI Inc. はじめに 名前 • nanko kazuhiro • X: @yesman_kakuteki • github: @stnamco 経歴 • 〜2018 ベンチャー色々 ◦ エンジニア • 2018〜 Quipper ◦ iOSエンジニア、iOSエンジニアリングマネージャー • 2020〜 (現在)カケハシ ◦ エンジニア、テックリード, 技術広報 自己紹介
5. © KAKEHASHI Inc. はじめに • Mutation Testingに興味を持った背景 • Mutation Testingとはどういうテスト手法か Agenda
6. Mutation Testingに興味を持った背景
7. © KAKEHASHI Inc. Mutation Testingに興味を持った背景 • i/A向けに公開されている電子お薬手帳アプリ • 2022年の8月にリリースされた • チーム構成は以下 ◦ エンジニア４人 ◦ QA１人 ◦ PdM１人 ◦ デザイナー１人 プロダクトの状況
8. © KAKEHASHI Inc. Mutation Testingに興味を持った背景 機能としてはまだMVPに近いものもあるので、一部は作り捨てを前提で実装を進めている。 そのため、単体テストについてもフルカバレッジを目指すというより、対象を絞って重点的にテスト を書いていくという方針。 関連 - パレートの法則 「結果の80％は、全体の20％の要素によって生み出されている」 - 犠牲的アーキテクチャ (https://martinfowler.com/bliki/SacrificialArchitecture.html) 単体テスト方針
9. © KAKEHASHI Inc. Mutation Testingに興味を持った背景 単体テストはCIで実行されている。 デプロイパイプラインモデル
10. © KAKEHASHI Inc. Mutation Testingに興味を持った背景 📝 プロダクトの外部品質担保に向けて、ただテストの量を増やすだけでなく 質を上げていきたい 🤔 速度や内部品質の評価・改善の方法は想像できるが、信頼性向上を目的と した単体テストの評価・改善ってどうやればいんだ？ 気になっていたこと
11. © KAKEHASHI Inc. Mutation Testingに興味を持った背景 書籍 「単体テストの考え方/使い方」を 読み進める中で、単体テストの信頼性を 構築する要素として偽陽性と偽陰性があ ることが理解できた。 ※本当はもっとちゃんと内容紹介したいが400P以上あるの で、、 単体テストの評価
12. © KAKEHASHI Inc. Mutation Testingに興味を持った背景 偽陽性のテストコード - 本来は合格すべき条件で、テストが失敗してしまう 偽陰性のテストコード - 本来は不合格すべき条件で、テストが合格してしまう 偽陽性/偽陰性のテストケースが多く含まれる場合、テストスイートの信頼性は 低い。言い換えれば、偽陽性率と偽陰性率が低ければそのテストの信頼性は高 いと判断できる。 テストコードの偽陽性/偽陰性
13. © KAKEHASHI Inc. Mutation Testingに興味を持った背景 偽陽性 - そもそもテストが失敗するので気づくことができる 偽陰性 - コードレビューなどで頑張る。 - 人間にミスはつきものなので、もっと機械的に検出を行なっていきたい。 一つの方法として、「エラーシーディング」と呼ばれる意図的に不具合を 仕込んで問題点を洗い出す手法がある。さらにこの手法を体系化しプロセ スまで定めたもので「Mutation Testing」というものがあると知った。 偽陽性/偽陰性の検出手法
14. Mutation Testingとは どういうテスト手法か
15. © KAKEHASHI Inc. MutationTestingとはどういうテスト手法か コード内にミュータントと呼ばれる「人工的な誤りを含むプログラム」を加え、それに 対するテストの反応を評価するホワイトボックステスト。 コードにミュータント(誤った実装)が加えられているので、テストは失敗することが期 待される。期待と反して成功したテストの数が少ないほど、正しくテストができている と判断。 Mutation Testing とは 補足: ホワイトボックステスト: アプリケーションの機能ではなく、アプリケーションの内部構造をテスト するソフトウェアテストの手法
16. © KAKEHASHI Inc. MutationTestingとはどういうテスト手法か Mutation Testing で利用するツール ミュータントの生成には専用のツールを利用できる。 Strykerは複数言語に対応してるし、Playgroundで動作 確認もしやすいのでおすすめ。 次のページ以降でPlayground使います。 補足: ツールの都合上、コードは .Net になっています。 自分でも触ってみたい方はこちら https://stryker-mutator.io/stryker-playground/
17. © KAKEHASHI Inc. MutationTestingとはどういうテスト手法か Mutation Testing のフロー 具体的には、右図のフローのように実 行される。
18. © KAKEHASHI Inc. MutationTestingとはどういうテスト手法か DEMOできなかった時向け: テスト対象 テスト対象のコードは左枠のも の。テストコードは右枠のもの。 コードは単純な加算と乗算の処 理。 テストの品質検証のためMutation Testingを実行してみる。
19. © KAKEHASHI Inc. MutationTestingとはどういうテスト手法か DEMOできなかった時向け: テスト実行結果1
20. © KAKEHASHI Inc. MutationTestingとはどういうテスト手法か 記載のようなコードがミュータントとして追 加される。 変更点 • 算術演算子が変更される ◦ ‘+’→ ‘-’ ◦ ‘*’→ ‘/’ DEMO補足: 生成されたミュータント
21. © KAKEHASHI Inc. MutationTestingとはどういうテスト手法か DEMOできなかった時向け: テスト実行結果2 加算の処理に追加された Mutantが生き残っている。 理由としてはテストコードの パラメータが a,b それぞれ 100と0 であり、その場合、 減算の算術演算子に書き換え られた場合も処理が成功して しまう。 これを防ぐには、追加でテス トケースを準備しておく必要 がある。
22. © KAKEHASHI Inc. MutationTestingとはどういうテスト手法か DEMOできなかった時向け: テストを修正 加算のテストケースに a,b それぞれ 100,10 を渡す処理 を追加した。 再度 Run Strykerを実行し、 ミュータントを撲滅できてい ることが確認できた。
23. © KAKEHASHI Inc. MutationTestingとはどういうテスト手法か Mutation Testing を実行したアウトカム • 品質評価 ◦ 信頼性に疑いのあるテストケースの割合を可視化できた ▪ 補足: この割合を Mutation Score という • 品質改善 ◦ 信頼性に疑いのあるテストケースを見つけることができた ◦ テストケースの修正方法の示唆を得られた ◦ etc..
24. © KAKEHASHI Inc. MutationTestingとはどういうテスト手法か 代表的なミュータントの種類 生成されるミュータントは複数種類ある。スライドに一部を記載。 • Decision Mutation ◦ デモで表示されていた算術演算子の差し替えはここに含まれる • Value Mutation • Statement Mutation • etc….
25. © KAKEHASHI Inc. MutationTestingとはどういうテスト手法か Decision Mutation プログラムで使用される論理演算子と算術演算子が変更され、プログラム内の全 体的な意思決定とその結果が変わる。 参照: https://en.wikipedia.org/wiki/Mutation_test ing
26. © KAKEHASHI Inc. MutationTestingとはどういうテスト手法か Value Mutation 定数の値 / メソッドで渡されるパラメーター / ループで使用される値を変更し て、ミュータントなプログラムを作成する。 大きい値が小さい値に変更されるかまたはその逆になる。 参照: https://en.wikipedia.org/wiki/Mutation_testing
27. © KAKEHASHI Inc. MutationTestingとはどういうテスト手法か Statement Mutation ミュータントを作成するために、コードのステートメント全体に変更が加えられ る。ステートメントの変更には、ステートメント全体の削除、コード内のステー トメントの順序の変更、コード内の別の場所へのステートメントのCopy&Paste、 元のコード内のいくつかのステートメントの繰り返しまたは複製などが含まれ る。 参照: https://en.wikipedia.org/wiki/Mutation_test ing
28. © KAKEHASHI Inc. MutationTestingとはどういうテスト手法か Mutation Testing の辛い点 • 実行時間が長い • 修正対象の洗い出しが煩雑
29. © KAKEHASHI Inc. MutationTestingとはどういうテスト手法か Mutation Testing の辛い点 - 実行時間が長い コードを解析して、ミュータントの生成/ミュータントの挿入を行いテスト実行するため実行時間がか なりかかる。そのため、PRをフックにしたCI組み込むなどは実行時間/コストの観点で難しいなという 感じた。
30. © KAKEHASHI Inc. MutationTestingとはどういうテスト手法か Mutation Testing の辛い点 - 修正対象の洗い出しが煩雑 ミュータントを生成する際は、一定のルールでランダムに生成されておりテストコードの問題点を明 らかにすることを意図して生成されるとは限らない。 要は「見かけ上コードは変更されているが、論理的な動作は変わらない」といった検出する必要のな いミュータントが入りうる。 こういった結果が続くと、Mutation Testing で検出された結果の偽陰性が高まり、確認優先度が下 がっていく。
31. © KAKEHASHI Inc. MutationTestingとはどういうテスト手法か Mutation Testing の導入案 1. weeklyやnightlyのバッチで実行。そのレポート結果を単体テスト改善のディスカッションのト ピックに使う ◦ 結局テストの品質を上げていくために大事なのは、チームで品質を考えられている状態を 作ることなので、その起点になるだけでも意義あるかなと思っている 2. PRなどで変更差分に対してのみ実行する ◦ GoogleもMutation Testingを導入している。変更差分のみに対して実行したり、不要な変 更は確認対象から外されるような仕組みを整えているらしい ▪ https://research.google/pubs/state-of-mutation-testing-at-google/ ▪ https://testing.googleblog.com/2021/04/mutation-testing.html
32. © KAKEHASHI Inc. 最後に まとめ • テストケースの信頼性を評価する観点として、偽陽性/偽陰性に注意できると良さそ う • Mutation Testingとは、プロダクトコードに意図的に不具合を仕込み、テストコー ドが失敗するか評価する手法 ◦ プロセスへの組み込みには検討項目がありそう
33. © KAKEHASHI Inc. 最後に 最後に一言 検証の品質を高めるために大事なのは、チームで品質を考えてチームで改善のアクショ ンを実行していくこと。今日の話が１つのきっかけになれば幸いです😀
34. © KAKEHASHI Inc. MutationTestingとはどういうテスト手法か [Appendix] 他の単体テスト品質改善施策 • 品質の理解を深めるための書籍を輪読会 ◦ https://kakehashi-dev.hatenablog.com/entry/2024/02/27/090000 • テストコードの規約を作る ◦ https://product.10x.co.jp/entry/test-coding-standards-in-10X-202303 • テストアーキテクチャを作る ◦ https://speakerdeck.com/goyoki/cetam
35. © KAKEHASHI Inc. 最後に 宣伝 カケハシテックブログ面白い記事多いのでぜひ読んでみて下さい！！🙏 https://kakehashi-dev.hatenablog.com/
36. 参考資料 https://testing.googleblog.com/2020/08/code-coverage-best-practices.html?keyword=consistently https://testing.googleblog.com/2021/04/mutation-testing.html https://goyoki.hatenablog.com/entry/2022/07/24/133033 https://www.school.ctc-g.co.jp/columns/nakai2/nakai286.html