Tweet
Tweet

Slide 1

Slide 1 text

© 2024 Wantedly, Inc. テストカバレッジを 100%にするということ omotesando.rb #93 Jan 11 2024 - Sora Ichigo

Slide 2

Slide 2 text

© 2024 Wantedly, Inc. 自己紹介 名前 市古 空 (Sora Ichigo) 所属 ● ウォンテッドリー株式会社 ● 新規プロダクト開発チーム ● DevOps 推進チームリード SNS ● X: @igsr5_ ● GitHub: @igsr5

Slide 3

Slide 3 text

© 2024 Wantedly, Inc. 自己紹介 過去発表

Slide 4

Slide 4 text

© 2024 Wantedly, Inc. 今日の話 Ruby リポジトリにおける 100% テストカバレッジの 運用経験と知見を話します

Slide 5

Slide 5 text

© 2024 Wantedly, Inc. 先に結論 テストカバレッジを使いこなして信頼できるテストを作ろう ● 信頼できるテストは PR マージの心理的負荷を下げる ● テストカバレッジは内部品質の定量化に役立つ ● 小さな 100% の数を増やしていくことが大事 ○ ❌ テストカバレッジを増やす / ✅ 信頼できるテストを増やす ● 100% のテストカバレッジが 100 %信頼できるわけではない ○ 特にレガシーコードと外部品質には要注意

Slide 6

Slide 6 text

© 2024 Wantedly, Inc. Agenda 1. 100% の事例紹介 2. 100% の恩恵 3. 100% にするための工夫 4. 現状の課題 ※ 100% とはテストカバレッジの値のことを指しています

Slide 7

Slide 7 text

© 2024 Wantedly, Inc. 1. 100% の事例紹介

Slide 8

Slide 8 text

© 2024 Wantedly, Inc. 事例 2023/12~現在の話 直近の新規開発で RSpec を重点的に書いています 可視化ツール https://coveralls.io/

Slide 9

Slide 9 text

© 2024 Wantedly, Inc. 解説 ● Line Coverage と Branch Coverage を計測 ○ Line Coverage のみだと心もとない ○ by simplecov-ruby/simplecov ● リポジトリ立ち上げ時から 100% を保持 ○ 重要なので後で触れます ● 2ヶ月運用してみて実際に恩恵や工夫が見つかった ○ 工夫すればそこまで大変じゃない！！ ○ こちらも重要なので後で触れます

Slide 10

Slide 10 text

© 2024 Wantedly, Inc. 2. 100% の恩恵

Slide 11

Slide 11 text

© 2024 Wantedly, Inc. 恩恵 信頼できるテストは PR マージの心理的負荷を下げる 1. 開発スピードが上がる 2. バグが減る 3. ライブラリバージョンが上げやすい

Slide 12

Slide 12 text

© 2024 Wantedly, Inc. 開発スピードが上がる ● 開発中の見落としは RSpec がすぐ教えてくれる ○ 手戻りが少ない ● テストを書きやすい環境が TDD を促進させる ○ TDD = テストを増やす、ではないので注意 ⚠ ● 自信を持ってリファクタリングできる ○ “脆きものよ、汝の名はソフトウェア ” ■ 引用 『リファクタリング(第2版): 既存のコードを安全に改善する』 ○ 一度体験すると自動テストがない世界には戻れない ... ※ TDD - テスト駆動開発

Slide 13

Slide 13 text

© 2024 Wantedly, Inc. バグが減る・ライブラリバージョンが上げやすい ● デプロイ前の問題発覚がされやすくなる ○ 言わずもがな ● CI が通れば OK という安心感 ○ もちろん分厚い自動テストの上には少数の手動テストが必要 ○ ただし “少数の” であることが重要 ● 効果のあった事例 ○ メジャーバージョン以外の Renovate PR を安心して Auto Merge できる

Slide 14

Slide 14 text

© 2024 Wantedly, Inc. 100% まで頑張る意味あるの？ 80% と 100% の差は数字以上に大きい ● 少しでもテストが信頼できないと人間は非効率な手動テストを実施する

Slide 15

Slide 15 text

© 2024 Wantedly, Inc. 100% まで頑張る意味あるの？ 80% と 100% の差は数字以上に大きい ● 少しでもテストが信頼できないと人間は非効率な手動テストを実施する ● 手動テストによる振る舞いの網羅的なチェックには必ず漏れが生じる ○ 漏れが生じるとそこにバグやインシデントリスクが生まれてしまう

Slide 16

Slide 16 text

© 2024 Wantedly, Inc. 100% まで頑張る意味あるの？ 80% と 100% の差は数字以上に大きい ● 少しでもテストが信頼できないと人間は非効率な手動テストを実施する ● 手動テストによる振る舞いの網羅的なチェックには必ず漏れが生じる ○ 漏れが生じるとそこにバグやインシデントリスクが生まれてしまう ● 手動テストありきの開発に慣れると自動テストを書こうというモチベが湧かない ○ テストカバレッジが減少 → 非効率な手動テストが増加、の悪循環

Slide 17

Slide 17 text

© 2024 Wantedly, Inc. 100% まで頑張る意味あるの？ 80% と 100% の差は数字以上に大きい ● 少しでもテストが信頼できないと人間は非効率な手動テストを実施する ● 手動テストによる振る舞いの網羅的なチェックには必ず漏れが生じる ○ 漏れが生じるとそこにバグやインシデントリスクが生まれてしまう ● 手動テストありきの開発に慣れると自動テストを書こうというモチベが湧かない ○ テストカバレッジが減少 → 非効率な手動テストが増加、の悪循環 ● もちろん必ずしも「テストカバレッジ 100% ならテストを信頼してOK」ではないが 一つの重要指標にはなり得る

Slide 18

Slide 18 text

© 2024 Wantedly, Inc. 3. 100% にするための工夫

Slide 19

Slide 19 text

© 2024 Wantedly, Inc. 工夫たち 1. テストカバレッジは可視化する 2. テストは初めから書く 3. 実装しながらテストを書く 4. 小さい100%から作る 5. テストコードを定期的にリファクタリングする ※ TDD - テスト駆動開発

Slide 20

Slide 20 text

© 2024 Wantedly, Inc. 特に重要 1. テストカバレッジは可視化する 2. テストは初めから書く 3. 実装しながらテストを書く 4. 小さい100%から作る ⭐ 5. テストコードを定期的にリファクタリングする ※ TDD - テスト駆動開発

Slide 21

Slide 21 text

© 2024 Wantedly, Inc. 1. テストカバレッジを可視化する これがないとそもそも100%かどうか分からない 可視化ツール https://coveralls.io/

Slide 22

Slide 22 text

© 2024 Wantedly, Inc. 1. テストカバレッジを可視化する それ以外の目的 ● モチベ維持 ○ テストカバレッジが下がったら CI を落とすと better ● テストコードの存在有無チェック ○ どこにテストがあってどこにテストがないのか？が知れる ○ 機能実装前にチェックしてなければテストを追加する

Slide 23

Slide 23 text

© 2024 Wantedly, Inc. 2. テストは初めから書く ● クラスやメソッドを追加したらテストも同時に追加する ○ 「テストを書く場所がある」という事実が大事 ○ 不思議と後からくる人もテストを書いてくれる ○ 例えば rails generate model と一緒に rails generate rspec:model も 実行する $ rails generate model user invoke active_record create db/migrate/20240111055652_create_users.rb create app/models/user.rb $ rails generate rspec:model user create spec/models/user_spec.rb

Slide 24

Slide 24 text

© 2024 Wantedly, Inc. 3. 実装しながらテストを書く ● コードの解像度が高いときにテストが書こう ○ 「何をテストすべきか？」を一番理解しているのはコードを書いている時 ● テスト駆動開発とも言う ○ “テストによって開発を推し進めることで動作する綺麗なコードを目指す ” ■ 『テスト駆動開発』(Kent Beck 著、和田卓人 訳)より意訳 ○ どうせ自動テストを書くなら他の視点でも活用しよう

Slide 25

Slide 25 text

© 2024 Wantedly, Inc. 4. 小さい100%から作る ⭐ ● 既にあるコードのテストカバレッジを改善したい時 ● 「この中ならテストカバレッジ 100%」の数を増やすべき ● 50%を量産してはダメ󰢃 50% 50% 50% 50% 50% < 少数の良いテスト の方が役立つ 100%

Slide 26

Slide 26 text

© 2024 Wantedly, Inc. 再掲: 100% まで頑張る意味あるの？ 80% と 100% の差は数字以上に大きい ● 少しでもテストが信頼できないと人間は非効率な手動テストを実施する ● 手動テストによる振る舞いの網羅的なチェックには必ず漏れが生じる ○ 漏れが生じるとそこにバグやインシデントリスクが生まれてしまう ● 手動テストありきの開発に慣れてしまうと自動テストを書こうというモチベが湧かない ○ テストカバレッジが減少 → 非効率な手動テストが増加、の悪循環 ● もちろん必ずしも「テストカバレッジ 100% ならテストを信頼してOK」ではないが 一つの重要指標にはなり得る

Slide 27

Slide 27 text

© 2024 Wantedly, Inc. 4. 小さい100%から作る ⭐ ● 中途半端なテストでは結局テストを信頼しきれない ○ ❌ テストカバレッジを増やす / ✅ 信頼できるテストを増やす ● 信頼できると信頼できないを混ぜない ○ つまりこういうこと hoge.rb テストカバレッジ fuga.rb テストカバレッジ 効果いまひとつ😢 50% 50% 効果あり💣 100% 0% 効果バツグン💥 100% 100%

Slide 28

Slide 28 text

© 2024 Wantedly, Inc. 5. テストコードを定期的にリファクタリングする ● 実装と同じくらいテストコードも負債化する ○ せっかく書いたテストが将来のテスト追加を阻まないように対策しよう ● xUnit Patterns を学ぶのがおすすめ ○ http://xunitpatterns.com/ で読めます ○ Test Smells を感じ取ったらテストコードを見直そう

Slide 29

Slide 29 text

© 2024 Wantedly, Inc. 4. 現状の課題

Slide 30

Slide 30 text

© 2024 Wantedly, Inc. 課題 1. レガシーコード 2. 外部品質

Slide 31

Slide 31 text

© 2024 Wantedly, Inc. 1. レガシーコード 問題 ● 対象機能が巨大かつ全体が密結合している ● 小さくテストできないので単体テストが書きにくい

Slide 32

Slide 32 text

© 2024 Wantedly, Inc. 1. レガシーコード 現状の対応 ● 新しく作り直す ● 気合いで少しずつリファクタリング ● 諦めて腐敗防止レイヤを挟む

Slide 33

Slide 33 text

© 2024 Wantedly, Inc. 1. レガシーコード やっていないこと ● テストピラミッドに反して結合テストをたくさん書く ○ Branch coverage の担保が辛くなるため ○ テストコードの負債化は避けるべき

Slide 34

Slide 34 text

© 2024 Wantedly, Inc. 2. 外部品質 ● 自動テストも開発者によって作られるプログラムの一つ ○ 内部品質よりにバイアスがかかってしまうことも多い ● 足りていない外部品質はなにか？を考えよう ○ 現実の利用者が十分間違えにくいインターフェースになっているか？ ○ パフォーマンスやセキュリティは十分か？

Slide 35

Slide 35 text

© 2024 Wantedly, Inc. まとめ テストカバレッジを使いこなして信頼できるテストを作ろう ● 信頼できるテストは PR マージの心理的負荷を下げる ● テストカバレッジは内部品質の定量化に役立つ ● 小さな 100% の数を増やしていくことが大事 ○ ❌ テストカバレッジを増やす / ✅ 信頼できるテストを増やす ● 100% のテストカバレッジが 100 %信頼できるわけではない ○ 特にレガシーコードと外部品質には要注意

Slide 36

Slide 36 text

© 2024 Wantedly, Inc. 参考文献 ● XUnit Test Patterns ● 『テスト駆動開発』(Kent Beck 著、和田卓人 訳) ● 『リファクタリング(第2版): 既存のコードを安全に改善する』（ Martin Fowler 著、児玉 公信, 友 野 晶夫, 平澤 章, 梅澤 真史 訳）

Slide 37

Slide 37 text

© 2024 Wantedly, Inc. © 2023 Wantedly, Inc.