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 to mutation testing
Search
kakehashi
May 23, 2024
Technology
3
510
Mutation Testingを活用して テスト品質を考える /introduction to mutation testing
「ユニットテスト新着トピック3選!イチからわかるイマドキのテスト」での登壇資料です
kakehashi
May 23, 2024
Tweet
Share
More Decks by kakehashi
See All by kakehashi
なぜ僕たちは 開発生産性指標を見ていないのか / Our Strategy for Development Productivity Metrics
kakehashi
13
3.6k
プロダクト拡大フェーズでプロダクト検証サイクル効率化を目指す過程で見えたもの / Streamlining Product Validation in Growth Phase
kakehashi
5
4.8k
OODAふりかえり 何って…ただ毎スプリント、違うふりかえり手法を採用してるだけだが? / Retrospectives with OODA
kakehashi
12
2.7k
よりアジャイルに向かう道のりとして、中止していたスクラムイベントを復活したら100Lの汗を流した話 / Reviving Scrum Events
kakehashi
2
180
Keeper of the Seven Keys 〜Four Keysとあと3つ〜
kakehashi
8
2.4k
OKRと「測りすぎ」 〜なりたい姿を、「測りすぎ」ないようにしながらどう追いかけるか〜/OKR and the tyranny of metrics
kakehashi
35
14k
複雑なビジネスルールに挑む:正確性と効率性を両立するfp-tsのチーム活用術 / Strike a balance between correctness and efficiency with fp-ts
kakehashi
6
4.2k
開発組織のOKRの作り方 / OKR in a development division
kakehashi
15
5.5k
実はたくさんほしい インシデント報告/more incident reports
kakehashi
0
680
Other Decks in Technology
See All in Technology
予知保全利用を目指した外観検査AIの開発 〜画像処理AIを用いた外観画像に対する異常検知〜
sadynitro
0
200
ベイジアンABテストってありなの? / Is Bayesian AB Testing Truly Effective?
ak_iyama
1
520
効果的なLLM評価法 LangSmithの技術と実践
knishioka
0
110
Next.js の fetch 拡張とキャッシュ機構の違いを理解する
ryo_manba
3
580
えにしテックさん15周年に寄せて〜万葉と私のこれまでの学び〜
nay3
42
26k
マイクロサービスの現場からプラットフォームエンジニアリングの可能性を探る!
abnoumaru
1
3.8k
個人開発でLIFFとMessagingAPIを使ってわかった5つのこと
diggymo
0
290
現場の失敗から学ぶ!プロダクトバックログアイテムの改善/Learn_from_On-Site_Failures!_Improving_Product_Backlog_Items
m_iyama
3
880
ANDPAD and Ruby
andpad
1
290
やさしいITを目指すために
ishity__
0
330
生成AIを使った業務効率化〜実践的なプロンプトと活用例の紹介〜
yoshi8__
0
380
EC2の脆弱性対応で何が使える? Inspector や SSM あたりを整理する #nakanoshima_dev
masahirokawahara
1
490
Featured
See All Featured
What's in a price? How to price your products and services
michaelherold
238
11k
The Language of Interfaces
destraynor
151
23k
Infographics Made Easy
chrislema
238
18k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
275
13k
Design by the Numbers
sachag
276
18k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
143
43k
Why Our Code Smells
bkeepers
PRO
331
56k
From Idea to $5000 a Month in 5 Months
shpigford
377
46k
Rails Girls Zürich Keynote
gr2m
91
13k
Rebuilding a faster, lazier Slack
samanthasiow
75
8.4k
Facilitating Awesome Meetings
lara
44
5.8k
In The Pink: A Labor of Love
frogandcode
138
22k
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