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
4
640
Mutation Testingを活用して テスト品質を考える /introduction to mutation testing
「ユニットテスト新着トピック3選!イチからわかるイマドキのテスト」での登壇資料です
kakehashi
May 23, 2024
Tweet
Share
More Decks by kakehashi
See All by kakehashi
目標設定は好きですか? アジャイルとともに目標と向き合い続ける方法 / Do you like target Management?
kakehashi
10
3k
Our Scrum without Estimates, and into the Trunk-based Development
kakehashi
2
280
なぜ僕たちは 開発生産性指標を見ていないのか / Our Strategy for Development Productivity Metrics
kakehashi
18
5.5k
プロダクト拡大フェーズでプロダクト検証サイクル効率化を目指す過程で見えたもの / Streamlining Product Validation in Growth Phase
kakehashi
6
8.4k
OODAふりかえり 何って…ただ毎スプリント、違うふりかえり手法を採用してるだけだが? / Retrospectives with OODA
kakehashi
14
3.7k
よりアジャイルに向かう道のりとして、中止していたスクラムイベントを復活したら100Lの汗を流した話 / Reviving Scrum Events
kakehashi
2
230
Keeper of the Seven Keys 〜Four Keysとあと3つ〜
kakehashi
8
3.3k
OKRと「測りすぎ」 〜なりたい姿を、「測りすぎ」ないようにしながらどう追いかけるか〜/OKR and the tyranny of metrics
kakehashi
35
15k
複雑なビジネスルールに挑む:正確性と効率性を両立するfp-tsのチーム活用術 / Strike a balance between correctness and efficiency with fp-ts
kakehashi
6
4.3k
Other Decks in Technology
See All in Technology
AutomatedLabを使って内部ペンテストを勉強しよう! -やられ社内ネットワークの自動構築-
n_etupirka
1
610
シフトレフトで挑む セキュリティの生産性向上
sekido
PRO
0
270
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
0
190
たくさん本を読んだけど 1年後には綺麗サッパリ!を乗り越えて 学習の鬼になるぞ👹
yum3
0
160
Datadog Cloud SIEMを使ってAWS環境の脅威を可視化した話/lifeistech-datadog-cloud-siem
gidajun
0
480
Classmethod Odyssey 登壇資料
yamahiro
0
390
[NIKKEI Tech Talk] KDDI/KAG Scrum & Community for Engineering Training
curanosuke
2
220
データ分析を支える技術 生成AI再入門
ishikawa_satoru
0
380
How to Think Like a Performance Engineer
csswizardry
4
590
GoとアクターモデルでES+CQRSを実践! / proto_actor_es_cqrs
ytake
1
160
【基調講演】変える、今ここから ― IoTとAIで紡ぐ未来
soracom
PRO
0
320
AIアシスタントの活用で品質の向上と開発ワークフローのスピードアップ
nagix
1
210
Featured
See All Featured
Code Review Best Practice
trishagee
58
16k
Optimizing for Happiness
mojombo
373
69k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
277
13k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
105
6.8k
YesSQL, Process and Tooling at Scale
rocio
166
14k
Large-scale JavaScript Application Architecture
addyosmani
506
110k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
29
2.5k
Designing with Data
zakiwarfel
96
5k
Learning to Love Humans: Emotional Interface Design
aarron
269
39k
The Mythical Team-Month
searls
217
43k
KATA
mclloyd
20
13k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
20
7.2k
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