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
テストカバレッジ100%を10年続けて得られた学びと品質
Search
もっち
September 04, 2025
Programming
2
910
テストカバレッジ100%を10年続けて得られた学びと品質
キチピー リジェクトコン【非公式】
https://connpass.com/event/363351/
での発表資料です。
もっち
September 04, 2025
Tweet
Share
More Decks by もっち
See All by もっち
もう外には出ない。より快適なフルリモート環境を目指して
mottyzzz
13
11k
「ちょっと古いから」って避けてた技術書、今だからこそ読もう
mottyzzz
12
7.2k
Other Decks in Programming
See All in Programming
contribution to astral-sh/uv
shunsock
0
540
Introduce Hono CLI
yusukebe
6
3.1k
GC25 Recap: The Code You Reviewed is Not the Code You Built / #newt_gophercon_tour
mazrean
0
110
AIと人間の共創開発!OSSで試行錯誤した開発スタイル
mae616
2
810
コードとあなたと私の距離 / The Distance Between Code, You, and I
hiro_y
0
190
EMこそClaude Codeでコード調査しよう
shibayu36
0
430
スマホから Youtube Shortsを見られないようにする
lemolatoon
27
34k
CSC509 Lecture 06
javiergs
PRO
0
270
あなたとKaigi on Rails / Kaigi on Rails + You
shimoju
0
190
AI 駆動開発におけるコミュニティと AWS CDK の価値
konokenj
5
250
3年ぶりにコードを書いた元CTOが Claude Codeと30分でMVPを作った話
maikokojima
0
650
オープンソースソフトウェアへの解像度🔬
utam0k
17
3.1k
Featured
See All Featured
Keith and Marios Guide to Fast Websites
keithpitt
411
23k
Designing for humans not robots
tammielis
254
26k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
10
890
Large-scale JavaScript Application Architecture
addyosmani
514
110k
Visualization
eitanlees
149
16k
Agile that works and the tools we love
rasmusluckow
331
21k
Designing Experiences People Love
moore
142
24k
Music & Morning Musume
bryan
46
6.9k
Testing 201, or: Great Expectations
jmmastey
45
7.7k
Typedesign – Prime Four
hannesfritz
42
2.8k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
9.7k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
Transcript
テストカバレッジ100%を 10年続けて得られた学びと品質 2025/09/04 松本明紘(@mottyzzz) キチピー リジェクトコン【⾮公式】
テストカバレッジ/コードカバレッジ 知っている⼈ 2
テストカバレッジ/コードカバレッジ 測定している⼈ 3
テストカバレッジ/コードカバレッジ ⽬標値を決定したことある⼈ 4
⾃⼰紹介 もっち(@mottyzzz) 松本明紘 株式会社 ⽇⽴製作所(2009年4⽉〜2023年2⽉) 株式会社 カケハシ(2023年2⽉〜) 好き:ビール🍻 コーヒー☕ 5
テストカバレッジ/コードカバレッジ テストがプログラムのソースコードをどの程度カバーしているかを測る指標 いろいろある。それぞれ守れるものも違う • 命令網羅 (Statement Coverage) (C0) • 分岐網羅
(Branch Coverage) (C1) • 条件網羅 (Condition Coverage) (C2) • 判定条件/条件網羅 (Decision/Condition Coverage) • 複合条件網羅 (Multiple Condition Coverage) • Modified Condition/Decision Coverage • 経路網羅 (Path Coverage) 6
前提 7
前提① カバレッジが⾼い ≠ ソースコードの品質が⾼い カバレッジが⾼くてもテストケースの質が低ければソースコードの品質は上がらない 8
前提② カバレッジが100% ≠ バグが無い 9
結論 10
100%は⽬指さなくて良い 11
だけど 部分的に100%にするのは良い 95%〜99%は選択肢にいれても良い 12
どんな環境で何を作っていたの? • プロダクトの種類: NoSQLサーバー • ユースケース:さまざま • 業種:⾦融、公共、電⼒、通信 • 提供⽅法:サーバーにインストールして動作
• ライフサイクル:半年や1年に1回のバージョンアップ • カバレッジ100%はPJ規約や組織の基準として決められていた(出会い) 代表的なものを1つ紹介(他に経験したプロジェクトも似たようなもの) 13
C1カバレッジを95%〜99%にすることで得られたもの • バグを検知できる(なんだかんだで出る) • テスタブルなコードに⾃然となる(ならないと無理) ◦ モジュール化 ◦ インタフェース活⽤ ◦
純粋関数への切り出し ◦ 早期リターン • プロダクトコードの理解が向上 • 不要なコードに気づける • リファクタリングの安全性 • ライブラリバージョンアップの安全性 14
99%から100%への壁 • 数値を上げるためだけのテストケースが増えてくる • テストケースを書けるようにするため 無理にプロダクトコードを変更することが出てくる (条件分岐を無理やりまとめたり) • assertのないテストコードを書く⼈が出てきたりする(質の低下) •
テストコードを書く⼯数もかなり増える(かなりというかめちゃくちゃ増える) • なんのために書いてるかわからなくなる • ただ、学習としては100%⽬指してやってみるのはめちゃくちゃ良い 15
結局 何%にするのが良い? 16
Google • ガイドラインを提供 ◦ 60%を「許容可能」 ◦ 75%を「推奨」 ◦ 90%を「模範的」 出展:https://testing.googleblog.com/2020/08/code-coverage-best-practices.html
17
Martin Fowler⽒ プログラミングの多くの側⾯と同じく、テストには思慮深さが必要だ。よいテスト を選るのに、TDD は有⽤だが、決して⼗分ではない。思慮深くテストを実施すれ ば、テストカバレッジはおそらく80%台後半か90%台になるだろう。100%は信⽤ ならない。カバレッジの数字ばっかり気にして、⾃分が何をやっているかわかってい ない⼈間のいる臭いがする。 出展:https://bliki-ja.github.io/TestCoverage 18
だいたい85%くらい? ちょうどよさそ う 19
10年の間に考えるきっかけがたくさんありました • 例外プロジェクトへの参加 ◦ PoC/プロトタイピング • 納期が厳しくテスト⼯数を減らさざるを得なかったり • 100%は意味ないでしょうって意⾒をぶつけたり •
⾃⾝がPLやPjMとなり、品質に対するオーナーシップが必要になったり • 単体テストフェーズなくしてみたり • そして、ミドルウェア開発からサービス開発へ 20
カバレッジの数値⾃体ではなく その決定の裏側にある ⽬指したい品質の状態が重要 21
作っているものによる • 航空機搭載ソフトウェア(DO-178CのレベルA) ※ ◦ 100% MC/DC(Modified Condition/Decision Coverage) ◦
100% 決定カバレッジ(Decision Coverage) ◦ 100% ステートメントカバレッジ(Statement Coverage) • 医療機器のソフトウェア(IEC 62304でクラスC) ◦ 具体的な⽬標数値はないが、⾼い品質が求められることは分かる • RDBMS(データベース) • タスク管理システム • 家電の組込みソフトウェア (※)出展: https://ldra.com/ldra-blog/do-178c-structural-coverage-analysis/ 22
ドメイン内の業務領域による 出展:ドメイン駆動設計を始めよう システム全体が同じ重要度ではないのでは? 23
モジュールやシステムの依存関係による • 様々なシステムから 様々な使われ⽅をするソフトウェア (依存される側) ◦ ロギング⽤のライブラリ ◦ Webフレームワーク ◦
データベースなどのミドルウェア ◦ OS • それらを使⽤するソフトウェア (依存する側) システムA システムB システムC ミドルウェア OS OS OS ライブラリ/FW OS ライブラリ/FW ライブラリ/FW 使⽤ 使⽤ 使⽤ 問題があった場合の影響範囲は?変更のしやすさは? 24
提供⽅法による • SaaS • Webからダウンロードできるインストーラー • モバイルアプリ(ストアから⼊⼿) • ベンダー製品 問題が発⽣した場合にすぐ解消できる?
25
リリース頻度による • 継続的 • ⽇次 • 週1回 • ⽉1回 •
年1回 つぎに開発するのは同じメンバー? 26
プロダクトのフェーズによる どのタイミングで品質を上げる? 出展:https://blog.leapt.co.jp/what-is-the-product-lifecycle-what-product-marketers-need-to-know 27
会社のブランド戦略による 何にお⾦を払ってもらっている? 出展: https://reiro.co.jp/blog/branding-equity/ ブランドエクイティ あるブランドが顧客や社会に対して持つ無形 の資産価値 知覚品質 顧客がブランドを⾒たり聞いたりした時に、 そのブランドに対して感じたり察知する品質
28
時代による カバレッジに関するところも⾊んな意⾒がある • ガードレールとして、評価関数として、これまで以上にカバレッジも重要 • ホワイトボックステストではなくブラックボックステストとして、 仕様や振る舞いを保っているかを確認する⽅が重要 ⽣成AIによってテストの考え⽅も変わってきた 29
開発チームで話そう カバレッジは話すきっかけになる ⽬標感のイメージにもなる 品質⽂化につながる 30
考え続けるのが⼤事 守りたいものは何か 捨てても良いものは何か カバレッジは考えるきっかけになる 31
⾃分が考え出したきっかけは アンチパターンとも呼ばれる カバレッジ100%が 当たり前にある環境からでした それが品質⽂化を作り出していた 32
この場がみなさんにとって 改めて考えるきっかけ となれば嬉しいです ご清聴ありがとうございました 33