日本の医療体験を、しなやかに。 © KAKEHASHI Inc. Mutation Testingを活用して テスト品質を考える nanko(@yesman_kakuteki) 2024.5.23 @MagicPod

© KAKEHASHI Inc. はじめに ● テストコードは書いてるけど、その品質をどう評価すればいいかわからな い人 ● テストに課題感はあるがどう改善すればいいか悩んでいる人 想定する聞き手

© KAKEHASHI Inc. はじめに ● テストコードの品質改善をしたくなった時のアイデアが持てる ● Mutation Testingがどういうテスト手法かわかる 発表のアウトカム

© KAKEHASHI Inc. はじめに 名前 ● nanko kazuhiro ● X: @yesman_kakuteki ● github: @stnamco 経歴 ● 〜2018 ベンチャー色々 ○ エンジニア ● 2018〜 Quipper ○ iOSエンジニア、iOSエンジニアリングマネージャー ● 2020〜 (現在)カケハシ ○ エンジニア、テックリード, 技術広報 自己紹介

© KAKEHASHI Inc. はじめに ● Mutation Testingに興味を持った背景 ● Mutation Testingとはどういうテスト手法か Agenda

Mutation Testingに興味を持った背景

© KAKEHASHI Inc. Mutation Testingに興味を持った背景 ● i/A向けに公開されている電子お薬手帳アプリ ● 2022年の8月にリリースされた ● チーム構成は以下 ○ エンジニア４人 ○ QA１人 ○ PdM１人 ○ デザイナー１人 プロダクトの状況

© KAKEHASHI Inc. Mutation Testingに興味を持った背景 機能としてはまだMVPに近いものもあるので、一部は作り捨てを前提で実装を進めている。 そのため、単体テストについてもフルカバレッジを目指すというより、対象を絞って重点的にテスト を書いていくという方針。 関連 - パレートの法則 「結果の80％は、全体の20％の要素によって生み出されている」 - 犠牲的アーキテクチャ (https://martinfowler.com/bliki/SacrificialArchitecture.html) 単体テスト方針

© KAKEHASHI Inc. Mutation Testingに興味を持った背景 単体テストはCIで実行されている。 デプロイパイプラインモデル

© KAKEHASHI Inc. Mutation Testingに興味を持った背景 📝 プロダクトの外部品質担保に向けて、ただテストの量を増やすだけでなく 質を上げていきたい 🤔 速度や内部品質の評価・改善の方法は想像できるが、信頼性向上を目的と した単体テストの評価・改善ってどうやればいんだ？ 気になっていたこと

© KAKEHASHI Inc. Mutation Testingに興味を持った背景 書籍 「単体テストの考え方/使い方」を 読み進める中で、単体テストの信頼性を 構築する要素として偽陽性と偽陰性があ ることが理解できた。 ※本当はもっとちゃんと内容紹介したいが400P以上あるの で、、 単体テストの評価

© KAKEHASHI Inc. Mutation Testingに興味を持った背景 偽陽性のテストコード - 本来は合格すべき条件で、テストが失敗してしまう 偽陰性のテストコード - 本来は不合格すべき条件で、テストが合格してしまう 偽陽性/偽陰性のテストケースが多く含まれる場合、テストスイートの信頼性は 低い。言い換えれば、偽陽性率と偽陰性率が低ければそのテストの信頼性は高 いと判断できる。 テストコードの偽陽性/偽陰性

© KAKEHASHI Inc. Mutation Testingに興味を持った背景 偽陽性 - そもそもテストが失敗するので気づくことができる 偽陰性 - コードレビューなどで頑張る。 - 人間にミスはつきものなので、もっと機械的に検出を行なっていきたい。 一つの方法として、「エラーシーディング」と呼ばれる意図的に不具合を 仕込んで問題点を洗い出す手法がある。さらにこの手法を体系化しプロセ スまで定めたもので「Mutation Testing」というものがあると知った。 偽陽性/偽陰性の検出手法

Mutation Testingとは どういうテスト手法か

© KAKEHASHI Inc. MutationTestingとはどういうテスト手法か コード内にミュータントと呼ばれる「人工的な誤りを含むプログラム」を加え、それに 対するテストの反応を評価するホワイトボックステスト。 コードにミュータント(誤った実装)が加えられているので、テストは失敗することが期 待される。期待と反して成功したテストの数が少ないほど、正しくテストができている と判断。 Mutation Testing とは 補足: ホワイトボックステスト: アプリケーションの機能ではなく、アプリケーションの内部構造をテスト するソフトウェアテストの手法

© KAKEHASHI Inc. MutationTestingとはどういうテスト手法か Mutation Testing で利用するツール ミュータントの生成には専用のツールを利用できる。 Strykerは複数言語に対応してるし、Playgroundで動作 確認もしやすいのでおすすめ。 次のページ以降でPlayground使います。 補足: ツールの都合上、コードは .Net になっています。 自分でも触ってみたい方はこちら https://stryker-mutator.io/stryker-playground/

© KAKEHASHI Inc. MutationTestingとはどういうテスト手法か Mutation Testing のフロー 具体的には、右図のフローのように実 行される。

© KAKEHASHI Inc. MutationTestingとはどういうテスト手法か DEMOできなかった時向け: テスト対象 テスト対象のコードは左枠のも の。テストコードは右枠のもの。 コードは単純な加算と乗算の処 理。 テストの品質検証のためMutation Testingを実行してみる。

© KAKEHASHI Inc. MutationTestingとはどういうテスト手法か DEMOできなかった時向け: テスト実行結果1

© KAKEHASHI Inc. MutationTestingとはどういうテスト手法か 記載のようなコードがミュータントとして追 加される。 変更点 ● 算術演算子が変更される ○ ‘+’→ ‘-’ ○ ‘*’→ ‘/’ DEMO補足: 生成されたミュータント

© KAKEHASHI Inc. MutationTestingとはどういうテスト手法か DEMOできなかった時向け: テスト実行結果2 加算の処理に追加された Mutantが生き残っている。 理由としてはテストコードの パラメータが a,b それぞれ 100と0 であり、その場合、 減算の算術演算子に書き換え られた場合も処理が成功して しまう。 これを防ぐには、追加でテス トケースを準備しておく必要 がある。

© KAKEHASHI Inc. MutationTestingとはどういうテスト手法か DEMOできなかった時向け: テストを修正 加算のテストケースに a,b それぞれ 100,10 を渡す処理 を追加した。 再度 Run Strykerを実行し、 ミュータントを撲滅できてい ることが確認できた。

© KAKEHASHI Inc. MutationTestingとはどういうテスト手法か Mutation Testing を実行したアウトカム ● 品質評価 ○ 信頼性に疑いのあるテストケースの割合を可視化できた ■ 補足: この割合を Mutation Score という ● 品質改善 ○ 信頼性に疑いのあるテストケースを見つけることができた ○ テストケースの修正方法の示唆を得られた ○ etc..

© KAKEHASHI Inc. MutationTestingとはどういうテスト手法か 代表的なミュータントの種類 生成されるミュータントは複数種類ある。スライドに一部を記載。 ● Decision Mutation ○ デモで表示されていた算術演算子の差し替えはここに含まれる ● Value Mutation ● Statement Mutation ● etc….

© KAKEHASHI Inc. MutationTestingとはどういうテスト手法か Decision Mutation プログラムで使用される論理演算子と算術演算子が変更され、プログラム内の全 体的な意思決定とその結果が変わる。 参照: https://en.wikipedia.org/wiki/Mutation_test ing

© KAKEHASHI Inc. MutationTestingとはどういうテスト手法か Value Mutation 定数の値 / メソッドで渡されるパラメーター / ループで使用される値を変更し て、ミュータントなプログラムを作成する。 大きい値が小さい値に変更されるかまたはその逆になる。 参照: https://en.wikipedia.org/wiki/Mutation_testing

© KAKEHASHI Inc. MutationTestingとはどういうテスト手法か Statement Mutation ミュータントを作成するために、コードのステートメント全体に変更が加えられ る。ステートメントの変更には、ステートメント全体の削除、コード内のステー トメントの順序の変更、コード内の別の場所へのステートメントのCopy&Paste、 元のコード内のいくつかのステートメントの繰り返しまたは複製などが含まれ る。 参照: https://en.wikipedia.org/wiki/Mutation_test ing

© KAKEHASHI Inc. MutationTestingとはどういうテスト手法か Mutation Testing の辛い点 ● 実行時間が長い ● 修正対象の洗い出しが煩雑

© KAKEHASHI Inc. MutationTestingとはどういうテスト手法か Mutation Testing の辛い点 - 実行時間が長い コードを解析して、ミュータントの生成/ミュータントの挿入を行いテスト実行するため実行時間がか なりかかる。そのため、PRをフックにしたCI組み込むなどは実行時間/コストの観点で難しいなという 感じた。

© KAKEHASHI Inc. MutationTestingとはどういうテスト手法か Mutation Testing の辛い点 - 修正対象の洗い出しが煩雑 ミュータントを生成する際は、一定のルールでランダムに生成されておりテストコードの問題点を明 らかにすることを意図して生成されるとは限らない。 要は「見かけ上コードは変更されているが、論理的な動作は変わらない」といった検出する必要のな いミュータントが入りうる。 こういった結果が続くと、Mutation Testing で検出された結果の偽陰性が高まり、確認優先度が下 がっていく。

© 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

© KAKEHASHI Inc. 最後に まとめ ● テストケースの信頼性を評価する観点として、偽陽性/偽陰性に注意できると良さそ う ● Mutation Testingとは、プロダクトコードに意図的に不具合を仕込み、テストコー ドが失敗するか評価する手法 ○ プロセスへの組み込みには検討項目がありそう

© KAKEHASHI Inc. 最後に 最後に一言 検証の品質を高めるために大事なのは、チームで品質を考えてチームで改善のアクショ ンを実行していくこと。今日の話が１つのきっかけになれば幸いです😀

© 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

© KAKEHASHI Inc. 最後に 宣伝 カケハシテックブログ面白い記事多いのでぜひ読んでみて下さい！！🙏 https://kakehashi-dev.hatenablog.com/

参考資料 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