テストカバレッジ100%を10年続けて得られた学びと品質

キチピー リジェクトコン【非公式】
https://connpass.com/event/363351/
での発表資料です。

Transcript

1. テストカバレッジ100%を 10年続けて得られた学びと品質 2025/09/04 松本明紘(@mottyzzz) キチピー リジェクトコン【⾮公式】
2. テストカバレッジ/コードカバレッジ 知っている⼈ 2
3. テストカバレッジ/コードカバレッジ 測定している⼈ 3
4. テストカバレッジ/コードカバレッジ ⽬標値を決定したことある⼈ 4
5. ⾃⼰紹介 もっち(@mottyzzz) 松本明紘 株式会社 ⽇⽴製作所(2009年4⽉〜2023年2⽉) 株式会社 カケハシ(2023年2⽉〜) 好き：ビール🍻    コーヒー☕ 5
6. テストカバレッジ/コードカバレッジ テストがプログラムのソースコードをどの程度カバーしているかを測る指標 いろいろある。それぞれ守れるものも違う • 命令網羅 (Statement Coverage) (C0) • 分岐網羅 (Branch Coverage) (C1) • 条件網羅 (Condition Coverage) (C2) • 判定条件／条件網羅 (Decision/Condition Coverage) • 複合条件網羅 (Multiple Condition Coverage) • Modified Condition/Decision Coverage • 経路網羅 (Path Coverage) 6
7. 前提 7
8. 前提① カバレッジが⾼い ≠ ソースコードの品質が⾼い カバレッジが⾼くてもテストケースの質が低ければソースコードの品質は上がらない 8
9. 前提② カバレッジが100％ ≠ バグが無い 9
10. 結論 10
11. 100％は⽬指さなくて良い 11
12. だけど 部分的に100%にするのは良い 95%〜99%は選択肢にいれても良い 12
13. どんな環境で何を作っていたの？ • プロダクトの種類： NoSQLサーバー • ユースケース：さまざま • 業種：⾦融、公共、電⼒、通信 • 提供⽅法：サーバーにインストールして動作 • ライフサイクル：半年や1年に1回のバージョンアップ • カバレッジ100％はPJ規約や組織の基準として決められていた(出会い) 代表的なものを1つ紹介(他に経験したプロジェクトも似たようなもの) 13
14. C1カバレッジを95%〜99％にすることで得られたもの • バグを検知できる(なんだかんだで出る) • テスタブルなコードに⾃然となる(ならないと無理) ◦ モジュール化 ◦ インタフェース活⽤ ◦ 純粋関数への切り出し ◦ 早期リターン • プロダクトコードの理解が向上 • 不要なコードに気づける • リファクタリングの安全性 • ライブラリバージョンアップの安全性 14
15. 99%から100%への壁 • 数値を上げるためだけのテストケースが増えてくる • テストケースを書けるようにするため 無理にプロダクトコードを変更することが出てくる (条件分岐を無理やりまとめたり) • assertのないテストコードを書く⼈が出てきたりする(質の低下) • テストコードを書く⼯数もかなり増える(かなりというかめちゃくちゃ増える) • なんのために書いてるかわからなくなる • ただ、学習としては100%⽬指してやってみるのはめちゃくちゃ良い 15
16. 結局 何%にするのが良い？ 16
17. Google • ガイドラインを提供 ◦ 60％を「許容可能」 ◦ 75％を「推奨」 ◦ 90％を「模範的」 出展：https://testing.googleblog.com/2020/08/code-coverage-best-practices.html 17
18. Martin Fowler⽒ プログラミングの多くの側⾯と同じく、テストには思慮深さが必要だ。よいテスト を選るのに、TDD は有⽤だが、決して⼗分ではない。思慮深くテストを実施すれ ば、テストカバレッジはおそらく80%台後半か90%台になるだろう。100%は信⽤ ならない。カバレッジの数字ばっかり気にして、⾃分が何をやっているかわかってい ない⼈間のいる臭いがする。 出展：https://bliki-ja.github.io/TestCoverage 18
19. だいたい85%くらい？ ちょうどよさそ う 19
20. 10年の間に考えるきっかけがたくさんありました • 例外プロジェクトへの参加 ◦ PoC/プロトタイピング • 納期が厳しくテスト⼯数を減らさざるを得なかったり • 100％は意味ないでしょうって意⾒をぶつけたり • ⾃⾝がPLやPjMとなり、品質に対するオーナーシップが必要になったり • 単体テストフェーズなくしてみたり • そして、ミドルウェア開発からサービス開発へ 20
21. カバレッジの数値⾃体ではなく その決定の裏側にある ⽬指したい品質の状態が重要 21
22. 作っているものによる • 航空機搭載ソフトウェア(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. ドメイン内の業務領域による 出展：ドメイン駆動設計を始めよう システム全体が同じ重要度ではないのでは？ 23
24. モジュールやシステムの依存関係による • 様々なシステムから 様々な使われ⽅をするソフトウェア (依存される側) ◦ ロギング⽤のライブラリ ◦ Webフレームワーク ◦ データベースなどのミドルウェア ◦ OS • それらを使⽤するソフトウェア (依存する側) システムA システムB システムC ミドルウェア OS OS OS ライブラリ/FW OS ライブラリ/FW ライブラリ/FW 使⽤ 使⽤ 使⽤ 問題があった場合の影響範囲は？変更のしやすさは？ 24
25. 提供⽅法による • SaaS • Webからダウンロードできるインストーラー • モバイルアプリ(ストアから⼊⼿) • ベンダー製品 問題が発⽣した場合にすぐ解消できる？ 25
26. リリース頻度による • 継続的 • ⽇次 • 週1回 • ⽉1回 • 年1回 つぎに開発するのは同じメンバー？ 26
27. プロダクトのフェーズによる どのタイミングで品質を上げる？ 出展：https://blog.leapt.co.jp/what-is-the-product-lifecycle-what-product-marketers-need-to-know 27
28. 会社のブランド戦略による 何にお⾦を払ってもらっている？ 出展: https://reiro.co.jp/blog/branding-equity/ ブランドエクイティ あるブランドが顧客や社会に対して持つ無形 の資産価値 知覚品質 顧客がブランドを⾒たり聞いたりした時に、 そのブランドに対して感じたり察知する品質 28
29. 時代による カバレッジに関するところも⾊んな意⾒がある • ガードレールとして、評価関数として、これまで以上にカバレッジも重要 • ホワイトボックステストではなくブラックボックステストとして、 仕様や振る舞いを保っているかを確認する⽅が重要 ⽣成AIによってテストの考え⽅も変わってきた 29
30. 開発チームで話そう カバレッジは話すきっかけになる ⽬標感のイメージにもなる 品質⽂化につながる 30
31. 考え続けるのが⼤事 守りたいものは何か 捨てても良いものは何か カバレッジは考えるきっかけになる 31
32. ⾃分が考え出したきっかけは アンチパターンとも呼ばれる カバレッジ100％が 当たり前にある環境からでした それが品質⽂化を作り出していた 32
33. この場がみなさんにとって 改めて考えるきっかけ となれば嬉しいです ご清聴ありがとうございました 33