Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Mutation Testingを活用して テスト品質を考える /introduction t...
Search
KAKEHASHI
PRO
May 23, 2024
Technology
7
2.7k
Mutation Testingを活用して テスト品質を考える /introduction to mutation testing
「ユニットテスト新着トピック3選!イチからわかるイマドキのテスト」での登壇資料です
KAKEHASHI
PRO
May 23, 2024
Tweet
Share
More Decks by KAKEHASHI
See All by KAKEHASHI
安定した基盤システムのためのライブラリ選定
kakehashi
PRO
3
130
"SaaS is Dead" は本当か!? 生成AI時代の医療 Vertical SaaS のリアル
kakehashi
PRO
4
620
堅牢な認証基盤の実現 TypeScriptで代数的データ型を活用する
kakehashi
PRO
2
340
時間がないなら、つくればいい 〜数十人規模のチームが自律性を発揮するために試しているいくつかのこと〜
kakehashi
PRO
25
7.6k
続・やっぱり余白が大切だった話
kakehashi
PRO
4
650
AIでめっちゃ便利になったけど、結局みんなで学ぶよねっていう話
kakehashi
PRO
2
750
システムとの会話から生まれる先手のDevOps
kakehashi
PRO
2
490
やっぱり余白が大切だった話
kakehashi
PRO
10
3.7k
貧民的プログラミングのすすめ
kakehashi
PRO
2
750
Other Decks in Technology
See All in Technology
AI時代にも変わらぬ価値を発揮したい: インフラ・クラウドを切り口にユーザー価値と非機能要件に向き合ってエンジニアとしての地力を培う
netmarkjp
0
130
Microsoft Defender XDRで疲弊しないためのインシデント対応
sophiakunii
1
310
Introduction to Sansan for Engineers / エンジニア向け会社紹介
sansan33
PRO
5
39k
AI エージェントと考え直すデータ基盤
na0
20
7.9k
セキュアな社内Dify運用と外部連携の両立 ~AIによるAPIリスク評価~
zozotech
PRO
0
120
毎晩の 負荷試験自動実行による効果
recruitengineers
PRO
5
180
cdk initで生成されるあのファイル達は何なのか/cdk-init-generated-files
tomoki10
1
670
マルチプロダクト環境におけるSREの役割 / SRE NEXT 2025 lunch session
sugamasao
1
730
Deep Security Conference 2025:生成AI時代のセキュリティ監視 /dsc2025-genai-secmon
mizutani
4
2.8k
Digitization部 紹介資料
sansan33
PRO
1
4.5k
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
18k
OpenTelemetryセマンティック規約の恩恵とMackerel APMにおける活用例 / SRE NEXT 2025
mackerelio
3
2k
Featured
See All Featured
How GitHub (no longer) Works
holman
314
140k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
Statistics for Hackers
jakevdp
799
220k
Fireside Chat
paigeccino
37
3.5k
Adopting Sorbet at Scale
ufuk
77
9.5k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Why Our Code Smells
bkeepers
PRO
337
57k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Documentation Writing (for coders)
carmenintech
72
4.9k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.7k
Building Applications with DynamoDB
mza
95
6.5k
Transcript
日本の医療体験を、しなやかに。 © 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月にリリースされた •
チーム構成は以下 ◦ エンジニア4人 ◦ QA1人 ◦ PdM1人 ◦ デザイナー1人 プロダクトの状況
© 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. 最後に 最後に一言 検証の品質を高めるために大事なのは、チームで品質を考えてチームで改善のアクショ ンを実行していくこと。今日の話が1つのきっかけになれば幸いです😀
© 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