PHPカンファレンス小田原2024

Slide 1

Slide 1 text

Slide 2

Slide 2 text

1. 自己紹介 2 Copyright © 2023 blessing software. All Rights Reserved. Illustrated by @amon_mikio Kanon 株式会社虎の穴ラボ samurai_se ↓詳しくは↓ ● 3次元に嫁が1人います。2次元にはたくさんいます。 ● 本業はKtor(Kotlin), Next.js(TypeScript)で副業がLaravel(PHP), Next.js(TypeScript) ● アニメと漫画と声優ラジオが好きです ● 推しは水瀬いのりさんと早見沙織さんです個人事業 blessing software

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

❗ CAUTION ❗ 8 ● 本業と副業の事例が入り混じります ○ 必ずしも、とらラボの事例ではないです ○ どっちでもやっていることもあります ● 普段からいろんな言語のテストを書いてます ○ PHPUnitに限った話ではないです ○ が、基本PHP前提でお話します ○ 本業ではJest/Cypress/JUnit ○ 副業ではJest/Cypress/PHPUnit ○ サンプルコードに言語混ざることをお赦しください・・・ Copyright © 2023 blessing software. All Rights Reserved. Illustrated by @amon_mikio

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

💡 テスト名には3つの要点を含め、明確にする 14 Copyright © 2023 blessing software. All Rights Reserved. Illustrated by @amon_mikio ● isExistPrefecture()は存在しない都道府県を指定したときエラーとなる ● validateStringValue()はrequiredがfalseのとき空文字でもエラーとならない日本人しかいないプロジェクトならテスト名は日本語でいい派です例

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

💡 カバレッジとは？ 25 Copyright © 2023 blessing software. All Rights Reserved. Illustrated by @amon_mikio ● テストコードによって到達されるコード行の尺度で基準としては以下 ● 分岐(Branch) ○ 条件分岐文でどれだけの分岐条件が実行されたか ● 行(Lines) ○ コードの各行がテストスイートで実行されたか。空行や{}だけの行も含む ● ステートメント(Stmt) ○ プログラム内の命令単位。なので空行や{}だけの行は含まない ● 関数(Funcs) ○ コード内の関数が実行されたかどうか

Slide 26

Slide 26 text

💡 適切なコードカバレッジを保つ 26 Copyright © 2023 blessing software. All Rights Reserved. Illustrated by @amon_mikio ● コードカバレッジは50~80%近辺を目安とするのがよさそう ● 10~40% ○ 低すぎる ● 90%以上 ○ 高すぎる ○ プロダクトのクリティカルな実装部分を超え、重箱の隅にまで視点をおくことは好ましくない

Slide 27

Slide 27 text

💡カバレッジ閾値に満たない場合、CIを中止する 27 Copyright © 2023 blessing software. All Rights Reserved. Illustrated by @amon_mikio ● Laravel 9から --coverage --min=n オプションが追加 ● 閾値に満たない場合、テストが失敗する ● 最初は、カバレッジレポートからわかった全体カバレッジの-5%あたりから始める ● 徐々に閾値を上げていくとにかく初期リリースまでの開発速度を重視するなら必ずしも必要な設定ではないただ主観だが、最初からカバレッジを高く保っていた方があとあとリファクタやリグレッションテストの工数を減らせてデグレのリスクを下げられるので、結果的に早い

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

33 Copyright © 2023 blessing software. All Rights Reserved. Illustrated by @amon_mikio 💡カバレッジレポートを精査し、テストされていない領域やそのほかの異常を検知する ● 閾値はトータルカバレッジを基準にしている ● それだけを監視しても、結局プロダクトの重要な部分が処理できているかはわからない ● 実際にカバレッジレポートを見て、ファイルごとのカバレッジを確認するのが重要(→定期的にSlack通知したりHTMLレポートを限定URLでホスティングするのが効果的) ● また、100%だとしてもそれが効果的なテストかはわからない(次で話します)

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

40 Copyright © 2023 blessing software. All Rights Reserved. Illustrated by @amon_mikio そこでMutation Testing ● ここではInfectionを使う前提で話します ● Mutation = 突然変異 ○ コードを意図的に変更し、バグを植え付ける ○ ex) a===0 を a!==0と変異させる ○ その後テストを実行し、正しいテストが書かれていればエラーとなるはず ○ エラーとならなかった箇所がきちんと検証されていないと判断できる変異の内容 Infectionの詳細についてはぺちこん関西の資料をみてね

Slide 41

Slide 41 text

41 Copyright © 2023 blessing software. All Rights Reserved. Illustrated by @amon_mikio Mutation Testingに関わる指標 ● Killed ○ 変異後、失敗すべきテストが失敗したことにより検知された変異の数 ● Survived ○ 変異後、失敗すべきテストが成功したことにより検知された変異の数つまり、Survivedの数が多ければ多いほどテストコードの品質が低い

Slide 42

Slide 42 text

42 Copyright © 2023 blessing software. All Rights Reserved. Illustrated by @amon_mikio Infectionの導入 ● 定期実行で全体のMutation Scoreを継続的に比較 ○ 全体実行はかなり遅い ○ ので週一程度でGHAを動かし、レポートをSlackに投げる ● CIで差分発生箇所に対してMutation Test ○ Mutation Scoreが一定を下回るとCIがコケる設定 ○ 新たに追加されたコードや修正分に関しては一定以上のMutation Scoreを担保できる

Slide 43

Slide 43 text

Slide 44

Slide 44 text