テストコードのガイドライン〜作成から運用まで〜

#phpcon #track5 テストコードのガイドライン〜作成から運⽤まで〜 PHP Conference Japan 2024 1 rikuto（@riku929hr）

#phpcon #track5 ⾃⼰紹介 rikuto（さとうりくと） @riku929hr（X/github/mixi2 etc.） 2020卒 SWE@株式会社オープンロジ ← BizDev@ソフトバンク株式会社
⼀児（0歳）の⽗野球観戦‧楽器（ホルン） 2

#phpcon #track5 3 Outline ガイドライン作成を決意するまで書籍から学んだテストの基本ガイドライン作成のポイント導⼊後の課題まとめ‧今後の課題

#phpcon #track5 4 テストといってもいろいろありますがここでは開発者が⾏う⾃動テスト（単体テスト‧統合テスト）を指します以降、これらを単に「テスト」と呼ぶことにします

#phpcon #track5 6 テストよくわからんエンジニアがガイドライン作成を決意するまでのお話

#phpcon #track5 7 とある開発タスクでリファクタリングしてた #phpcon #track5

#phpcon #track5 8 リファクタしたらテストが落ちた！

#phpcon #track5 9 挙動が変わらないからテストは落ちないはず #phpcon #track5

#phpcon #track5 （すべてのコードではなく⼀部ですが） • 何を検証したいのか、パッと⾒でわからないテストコードがある • Controllerのテストだけ厚く書かれており、実⾏に時間がかかってストレス ◦ オープンロジではLaravel（MVC）を使っています •
プロダクションコードはしっかりレビューされる⼀⽅、テストコードはほとんどレビューされないこともある 10 よく⾒渡すとこんな状況

#phpcon #track5 11 テストカバレッジが低く、テストに対する問題意識が⾼くなっていた開発組織として課題の共通認識はあったものの、改善に着⼿できていない状態だった社内の機運の⾼まり

#phpcon #track5 ガイドライン作ればいいのでは？ 12 #phpcon #track5

#phpcon #track5 13 そもそもいいテスト‧ テストコードって何？

#phpcon #track5 14 読書会やりました「単体テストの考え⽅/使い⽅」 https://book.mynavi.jp/ec/products/detail/id=134252 1回 1時間×15回＝ 15時間
かけて読みました

#phpcon #track5 15 それ以外にお世話になった本たち www.shuwasystem.co.jp/book/b620733.html www.sbcr.jp/product/4815608750/ www.seshop.com/product/detail/25037 www.oreilly.co.jp/books/9784873119656/

#phpcon #track5 16 ここからはガイドラインの元になった知識を紹介します #phpcon #track5

#phpcon #track5 17 Outline ガイドライン作成を決意するまで書籍から学んだテストの基本 • なぜテストするのか • 振る舞いをテストするということ
• 何をどのくらいテストすればいいのか • 認知負荷を下げるための⼯夫ガイドライン作成のポイント導⼊後の課題まとめ‧今後の課題

#phpcon #track5 19 なぜテストするのか少なくともリグレッションテストにおける⾃動テストの⽬的とは、成⻑し続けるプロダクトを安全にリリースできる状態を、持続可能なコストにキープし続けることだとわかります。（テスト⾃動化実践ガイド p29）「バグを捕捉すること」は、テストの動機の⼀部にすぎない。（中略）同等に重要なものは、変化を可能とする能⼒を備えておくため、
という理由である。新機能追加、コードの健全性に主眼を置いたリファクタリングの実施、（中略）どれを⾏っていようが、⾃動テストは間違いを素早く捕捉でき、そのおかげで信頼性を保ちつつソフトウェアを変更できるようになる。（Googleのソフトウェアエンジニアリング 11章テスト概観）バグを早い段階で捕捉し、変更容易性を保つ

#phpcon #track5 20 良いテストとは • バグを正しく検出できる • ⾃信を持ってコードを変更できる

#phpcon #track5 21 良いテストとは • バグを正しく検出できる • ⾃信を持ってコードを変更できる実装の詳細ではなく振る舞いをテストすること

#phpcon #track5 22 実装の詳細？？振る舞い？？

#phpcon #track5 24 実装の詳細と振る舞い最終的な出⼒関数が返す結果（例）テスト対象の処理の結果、得られた値が意図したものになっていることを検証する
（例）テスト対象のコードから呼ばれる関数が、想定通りに呼ばれていることを検証する実装の詳細振る舞い具体的な処理の中⾝

#phpcon #track5 25 1つ例を挙げてみてみましょう

#phpcon #track5 26 実装の詳細のテスト（例）代表例はモック[*]を利⽤したテスト final class Checkout { public
function execute(int $totalPrice): int { if ($this->discountService->needsDiscount($totalPrice)) { // 割引処理 $checkoutPrice = $this->discountService->discount($totalPrice); } } } 「1000円以上で100円割引」というロジックを考えてみる ※不完全なコードであることはご容赦くださいこの関数（execute）のテストについて discountServiceをモックにして書いてみる [*] 厳密にはテストダブルという表現が正しいですが、説明を簡単にするため聞き馴染みのあるモックという⾔葉を使っています

#phpcon #track5 27 実装の詳細のテスト（例） public function test_1000円未満の場合は割引されない() { $discountServiceMock =
$this->createMock(DiscountService::class); $discountServiceMock ->expects($this->once()) ->method('needsDiscount') // needsDiscountメソッドが1度だけ ->with(500) // 引数500で呼ばれることを確認して ->willReturn(false); // falseを返すようにmockする $discountServiceMock ->expects($this->never()) // discountメソッドが呼ばれないことを確認 ->method('discount'); $checkout = new Checkout($discountServiceMock); $checkout->execute(500); }

#phpcon #track5 28 実装の詳細のテスト（例） public function test_1000円未満の場合は割引されない() { $discountServiceMock =
$this->createMock(DiscountService::class); $discountServiceMock ->expects($this->once()) ->method('needsDiscount') // needsDiscountメソッドが1度だけ ->with(500) // 引数500で呼ばれることを確認して ->willReturn(false); // falseを返すようにmockする $discountServiceMock ->expects($this->never()) // discountメソッドが呼ばれないことを確認 ->method('discount'); $checkout = new Checkout($discountServiceMock); $checkout->execute(500); } 割引されない条件を discountメソッドが呼ばれないことでテストしている if ($this->discountService->needsDiscount($totalPrice)) { // 割引処理 $checkoutPrice = $this->discountService->discount($totalPrice); } テスト対象のコード

#phpcon #track5 29 仕様変更が⼊ったら… 1000円以上で100円の割引に加え、無条件に50円引きが追加されたら…？ public function execute(int $total)
{ if ($this->discountService->needsDiscount($total)) { $total = $this->discountService->discount($total); } // 50円引き！ $checkoutPrice = $this->sale50YenOff($total); } ※雑なコードであることはご容赦ください discount()以外に割引処理が⼊った！

#phpcon #track5 30 テストが仕様変更に追従しない public function test_1000円未満の場合は割引されない () { $discountServiceMock
= $this->createMock(DiscountService::class); $discountServiceMock ->expects($this->once()) ->method('needsDiscount') // needsDiscountメソッドが1度だけ ->with(500) // 引数500で呼ばれることを確認して ->willReturn(false); // falseを返すようにmockする $discountServiceMock ->expects($this->never()) // discountメソッドが呼ばれないことを確認 ->method('discount'); $checkout = new Checkout($discountServiceMock); $checkout->execute(500); } 100円引きの関数（discount）の呼び出ししか確認していないので、本来失敗しなければいけないテストが通過してしまう無条件に50円引きのはずだが…

#phpcon #track5 31 テストが仕様変更に追従しない public function test_1000円未満の場合は割引されない () { $discountServiceMock
= $this->createMock(DiscountService::class); $discountServiceMock ->expects($this->once()) ->method('needsDiscount') // needsDiscountメソッドが1度だけ ->with(500) // 引数500で呼ばれることを確認して ->willReturn(false); // falseを返すようにmockする $discountServiceMock ->expects($this->never()) // discountメソッドが呼ばれないことを確認 ->method('discount'); $checkout = new Checkout($discountServiceMock); $checkout->execute(500); } 100円引きの関数（discount）が呼ばれないことしか確認していないので、本来失敗しなければいけないテストが通過してしまう無条件に50円引きのはずだが… バグを正しく検出できない！時間の都合上触れませんがコードの変更もしづらくなります

#phpcon #track5 32 どうすればいいのか振る舞いをテストすれば、テストも仕様変更に追従する public function test_1000円未満では割引されない() { $checkout
= new Checkout(); $this->assertSame(999, $checkout->execute(999)); } public function test_1000円以上で100円割引される() { $checkout = new Checkout(); $this->assertSame(1400, $checkout->execute(1500)); } 最終的な結果（＝振る舞い）を確認すれば、バグは正しく検出される関数を実⾏して得られた結果が、期待する値になっているかを確認する

#phpcon #track5 33 振る舞いをテストできるコードを書こう final class DiscountService { // 割引するかの判定
public function needsDiscount(int $total): bool { return $total >= self::MINIMUM_DISCOUNT_PRICE; } // 割引処理 public function discount(int $total): int { return $total - self::DISCOUNT_AMOUNT; } } 実装の詳細である割引判定ロジックが publicメソッド実装の詳細を公開すると、振る舞いをテストしにくい割引判定と割引処理を呼び出し先に委ねている

#phpcon #track5 34 振る舞いをテストできるコードを書こう final class DiscountService { // 割引するかの判定
private function needsDiscount(int $total): bool { return $total >= self::MINIMUM_DISCOUNT_PRICE; } // 割引処理 public function execute(int $total): int { // 割引判定 if ($this->needsDiscount($total)) { return $total - self::DISCOUNT_AMOUNT; } return $total; } 振る舞いだけを公開すると、振る舞いのテストが書ける！実装の詳細である割引判定ロジックが privateメソッド振る舞いである割引処理の結果だけ publicにして公開する

#phpcon #track5 35 テックブログ書いてます https://zenn.dev/openlogi/articles/unit-test-principles 今回詳しく説明しきれなかった実装の詳細のテストから振る舞いのテストへのリファクタリングにも触れています

#phpcon #track5 36 モック[*]の使い⽅モックの利⽤は最⼩限にするのがお得！使ってはいけない、ということではないテストしにくいものをテストするのには有益な道具⾃分たちで管理しないリソース（管理下にない依存）だけにする [*] 厳密にはテストダブルという表現が正しいですが、説明を簡単にするため
聞き馴染みのあるモックという⾔葉を使っています外部の通知システムメール送受信外部サービスのAPI

#phpcon #track5 38 課題として認識されていたこと開発チームの課題として「どこにどんなテストを書けばいいかわからない」という声があがっていた

#phpcon #track5 39 テストには「レベル」がある単体統合 E2E （現実的に）実⾏可能なテストケースの数⾼速⾼決定性
低速忠実レベルごとに⻑所と短所がある決定性：≒冪等性何回やっても同じ結果になる性質

#phpcon #track5 40 各テストレベルごとの役割単体 E2E 特徴単⼀のプロセスで完結するため、実⾏時間が短く決定性が⾼い短所
テストで実⾏されるコード量が少なく、忠実性が⼩さい⻑所細かいテストケースをたくさんテストできる正常系に加え異常系をたくさんテストするレベル低のテスト統合

#phpcon #track5 41 各テストレベルごとの役割単体統合 E2E 特徴 DB等のリソースへアクセスを⾏う。実⾏時間が⻑くコストがかかるが、忠実
短所実⾏できるテストケース数が限られてくる⻑所テストで実⾏されるコード量が多く、忠実性が⾼い実⾏するテストケースを絞りモジュール‧リソース間の疎通に重点を置いたテストにするレベル⾼のテスト

#phpcon #track5 42 ⽤語の問題点学派/考え⽅や個⼈によって定義、捉え⽅が異なる実際のコードに紐つけて考えたほうがわかりやすい「単体テスト」「統合テスト」… 参考：https://gihyo.jp/dev/serial/01/savanna-letter/0003

#phpcon #track5 43 コードに紐付けて考えるドメインロジック Service Controller E2E (View) オープンロジの技術スタックである
Laravel（MVC+Service）にざっくり当てはめる Modelはここに含まれると思いますが誤解を招かないようドメインロジックとしました⾼速⾼決定性低速忠実

#phpcon #track5 44 各レベルごとのテストの書き⽅ドメインロジックのテスト（レベル低のテスト） DB等の外部リソースへのI/Oがない‧少ないもの正常系と異常系をたくさんテストする Serviceのテスト（レベル中のテスト） DB等へのリソースへアクセスを⾏うもの正常系と、そのテストでしか検証できない異常系をテストする
Controllerのテスト（レベル⾼のテスト） E2Eに近い領域で、実⾏できるテストケースが限られる意図したレスポンスが返ることをテストする正常系と、Controllerのテストでしか検証できない異常系をテストする

#phpcon #track5 45 この節のまとめテストにはレベルがあり、それぞれ⻑所‧短所がある使⽤するリソースや実⾏コストで分類する、googleが提唱している「テストサイズ」という分類⽅法があります。今回紹介したのはこの「テストサイズ」の考え⽅ともいえます。⻑所‧短所を理解し、レベルごとに適したテストを書く

#phpcon #track5 // NG: 認知負荷の高い例 $this->assertSame(in_array($result, 'value', true), true); //
OK: 適切なAssertionを使うと読みやすくなる $this->assertContains($result, 'value'); テストが落ちたときのエラーの⽂⾔もわかりやすくなります 47 認知負荷を下げるための⼯夫関数の命名は検証したいことを具体的に表現する // NG: 検証したい内容が不明瞭 public function test_validation_error() // OK: テストケースをわかりやすく書く public function test_お届け予定日を過去の日付に設定するとエラー () 適切なアサーションを使うちょっとしたことで可読性は向上する

#phpcon #track5 49 意気込んで作った！ #phpcon #track5

#phpcon #track5 50 初稿のレビューで撃沈本に書いてあることをそのまま書いてしまっていたスタッフエンジニアのレビューで「もっと具体的な⾏動に結びつくようにすべき」との指摘がレビュー時の実際のslackです

#phpcon #track5 51 「具体的な⾏動に結びつく」とは？これはオープンロジではこう書く、という具体的な書き⽅「教科書の丸コピ」ではNG

#phpcon #track5 52 厳しくしすぎない https://gigazine.net/news/20240929-rule-experiences-and-emotions/ https://www.universiteitleiden.nl/en/news/2024/09/why-rules-dont-work-for-some-of-the-population 何かのルールで⼈々の⾏動が阻害されたとき、その経験が⼈々にネガティブな感情を残し、規則を順守する意欲を失わせる可能性があるといいます。
（Gigazine記事より引⽤）ライデン⼤学（オランダ）Ritsart Plantengaの研究ルールが厳しい（⾏動を阻害される）と、守る意欲が低下する

#phpcon #track5 53 「教科書通り」にはできない #phpcon #track5

#phpcon #track5 54 ⼀⽅で、具体的な⾏動に結びつくある程度まとまったルールを作りたい #phpcon #track5

#phpcon #track5 55 どうする…？

#phpcon #track5 参考にしたもの 56 Reactでよく使われる、代表的な状態管理ライブラリの公式スタイルガイド https://redux.js.org/style-guide/ Redux Style Guide

#phpcon #track5 Redux Style Guide 57 重要度別にPriorityがついているこの基になったというVue Style GuideはPriority
Dまでありました Priority Description A 必須。必ず守ること B 強い推奨。可能な限り守る C 複数の選択肢があった場合のデフォルト

#phpcon #track5 58 「テストコードのスタイルガイド」にしました重要度を定め、必ず守りたいルールとそうでないものに分ける具体的な書き⽅が明確にわかるようにする Redux Style Guideにインスパイアされ「ガイドライン」ではなく「スタイルガイド」という名前に

#phpcon #track5 59 スタイルガイドの中⾝（⼀例）絶対に守ってほしいことは「Priority: A」モックを多⽤しない各レイヤーで何をテストすればいいか関数の命名はテストで検証したいことを具体的に書く守ってほしいけど、事情によっては守りにくいそうなものは「Priority:
B」 DBを使うテストにおいて、DBのtransactionでデータをリセットしない現状A、Bほど重要でないが、書いておきたいものは「Priority: C」適切なAssertionを利⽤する

#phpcon #track5 60 可能な限りサンプルをつけたすべてではないが、サンプルがすぐに⽤意できるものは記載し、実際にどのようなコードを書けばよいかがわかるように

#phpcon #track5 61 Outline ガイドライン作成を決意するまでテストの基本ガイドライン作成のポイント導⼊後の課題まとめ‧今後の課題

#phpcon #track5 62 「テストコードのスタイルガイド」策定後、⼦供が⽣まれまもなく育休へ… #phpcon #track5

#phpcon #track5 63 スタイルガイド導⼊後半年経ち、 rikutoの育休復帰を機にふりかえりを実施 #phpcon #track5

#phpcon #track5 64 実際に得られた声毎回ではないものの、レビュー時の指摘の参考にしています。 ※事前に⾏った、開発メンバーに対するアンケートの回答をそのまま記載しています PRを出す時、テストの書き⽅これで良さそうかのチェックにちょこちょこ利⽤させてもらっています！ガイドラインあるおかげで、ガイドライン⾒てねでレビュー指摘できるようになったので、助かってます

#phpcon #track5 65 その⼀⽅で…

#phpcon #track5 66 実際に得られた声② ※事前に⾏った、開発メンバーに対するアンケートの回答をそのまま記載していますあまり浸透してなさそうなとこに課題感を感じる個⼈的にもあまり意識できてない時が多く、今⾒返してみるとAのライン守れてないPRレビューしたこと結構あるなという感じです... 新しく⼊った⼈として…存在は知っていたけれどもちゃんと意識できていたかで⾔うとNOでした。
直近テストコード書く機会があり参照したところとても参考になったので浸透していけるといいなと思いました

#phpcon #track5 67 定着していないルールが守りづらい以前に、ルールそのものの存在が忘れられてしまう

#phpcon #track5 68 スタイルガイド導⼊で得られた学び作ったものの定着を考えていくことも重要「作って終わり」にしてはいけない！

#phpcon #track5 69 Outline ガイドライン作成を決意するまでテストの基本ガイドライン作成のポイント導⼊後の課題まとめ‧今後の課題

#phpcon #track5 70 まとめテストの⽬的は、バグを早い段階で捕捉し、変更容易性を保つということテストコードのスタイルガイドを作成し、開発チームに展開したコーディングガイドラインは具体的な⾏動につながる内容にすることが⼤事作って終わりにするのではなく、定着させるための施策も重要

#phpcon #track5 71 今後の課題定着させるための施策の実⾏浸透させるための啓蒙活動 PR-Agent等による⾃動レビューふりかえり‧スタイルガイドの⾒直し定期的にふりかえり、より開発チームに合うようにチューニングしていく

#phpcon #track5 72 参考⽂献⼀覧書籍『単体テストの考え⽅/使い⽅』Vladimir Khorikov(著), 須⽥智之(訳), マイナビ出版『ソフトウェアテストの教科書
第2版』布施昌弘ほか, SBクリエイティブ『Good Code, Bad Code』Tom Long(著), 秋勇紀ほか(訳), ⼭本⼤祐(監訳), 秀和システム『テスト⾃動化実践ガイド』末村拓也, 翔泳社『Googleのソフトウェアエンジニアリング』Titus Wintersほか(編), ⽵辺靖昭(監訳), 久富⽊隆⼀(訳), オライリー‧ジャパン Web サバンナ便り〜ソフトウェア開発の荒野を⽣き抜く〜 https://gihyo.jp/dev/serial/01/savanna-letter/0003 ほか, 最終閲覧 2024/12/20

#phpcon #track5 73 ありがとうございました！

テストコードのガイドライン 〜作成から運用まで〜

テストコードのガイドライン 〜作成から運用まで〜

More Decks by Rikuto Sato

Other Decks in Programming

Featured

Transcript

テストコードのガイドライン〜作成から運用まで〜

テストコードのガイドライン〜作成から運用まで〜