Slide 1
Slide 1 text
2023 年 6 月 24 日 (土)
PHPカンファレンス福岡 @stwile871
フレームワークが生み出す
負債や複雑さに対して、
PHPUnitと付き合っていく
Slide 2
Slide 2 text
自己紹介
スタヰル(@stwile871)
● PHPer歴・TDD歴6年目
● 名古屋在住ですが、2･3ヶ月毎に東京に出張
● 筋トレ🏋とウヰスキー🥃を嗜
● ロックマンエグゼ好きを拗らせてWeb業界に入門
● 好きな関数は sprintf()
Slide 3
Slide 3 text
Q. ところで皆さんご存知ですか？
Slide 4
Slide 4 text
FWのバージョンを上げるとどうなるのか
Slide 5
Slide 5 text
どうなるのか？
Slide 6
Slide 6 text
何もしてないのに壊れた
＼(^o^)／
＼(^o^)／
Slide 7
Slide 7 text
もう二度と＼(^o^)／らないために…！！
Slide 8
Slide 8 text
アジェンダ
1. FWのアップデート事故からの考察
2. テストクラスの罠
Slide 9
Slide 9 text
とある架空のアプリケーション
● FWのバージョンアップ
Slide 10
Slide 10 text
具体的な事故
ソート機能が
期待するものではなくなっていた
Slide 11
Slide 11 text
要件
TODOのリストを返す
● 更新日時
● 降順
Slide 12
Slide 12 text
要件
TODOのリストを返す
● 更新日時
● 降順 昇順
Slide 13
Slide 13 text
ちょっと待ってください。
Slide 14
Slide 14 text
悔しいポイント
🦁テストは書いていた🦁
Slide 15
Slide 15 text
どんなテストだったのか？
Slide 16
Slide 16 text
テストの概要
● API（Integration）のテスト
● モジュール（Unit）のテスト
Slide 17
Slide 17 text
事実確認
● モジュールのテスト ＞ APIのテスト
● APIのテストはMockを多用
Slide 18
Slide 18 text
原因と考察
● モジュールのテスト ＞ APIのテスト
● APIのテストはMockを多用
● 機能を担保するテストではなかった
● ライブラリの依存に対処できていなかった
Slide 19
Slide 19 text
つまり？
Slide 20
Slide 20 text
原因と考察
要件を満たして品質を担保するテスト
Slide 21
Slide 21 text
原因と考察
要件を満たして品質を担保するテスト
開発速度とカバレッジだけ高いテスト
Slide 22
Slide 22 text
テストピラミッドを信じてテストを書いていた
E2E
Integration
Unit
Slide 23
Slide 23 text
Unit ＞ Integration
E2E
Integration
Unit
本来のテストピラミッド
Slide 24
Slide 24 text
TODOアプリのテストピラミッド
E2E
Integration
Unit
Unit ＞ Integration
Slide 25
Slide 25 text
原因と考察に基づく比較
E2E
Integration
Unit
● 機能を担保するテストではなかった
● ライブラリの依存に対処できていなかった
Slide 26
Slide 26 text
原因と考察に基づく比較
E2E
Integration
Unit
● 機能を担保するテストではなかった
● ライブラリの依存に対処できていなかった
間違ってなさそう💧
Slide 27
Slide 27 text
もう少し図解
Slide 28
Slide 28 text
僕らが作っていたテスト
● プロダクトコード
● FW内の処理
● 依存ライブラリの処理の 振る舞い(mock)
● 入力
ブラックボックスが
処理を振る舞うテスト
Slide 29
Slide 29 text
品質を担保できるテスト
● プロダクトコード
● FW内の処理
● 依存ライブラリの処理
● 入力
ブラックボックスが
処理を行うテスト
Slide 30
Slide 30 text
結論
FWのアップデートには
Integrationテストを書こう
Slide 31
Slide 31 text
！！！！！！！！！！
！ここから本題です！
！！！！！！！！！！
Slide 32
Slide 32 text
残る疑問
E2E
Integration
Unit
ユニットテストをたくさん書いていたのに
品質を担保できなかったのはなぜ❓❓❓
Slide 33
Slide 33 text
？？？
「一体いつから
Unitテストがクラス単位だと
錯覚していた？」
？？？
Slide 34
Slide 34 text
No content
Slide 35
Slide 35 text
Unit（単体）テストは難しい
Slide 36
Slide 36 text
Unit（単体）テストは文脈ごとに意味が変わる
から難しい
Slide 37
Slide 37 text
各テスト定義（文脈）を比較
Slide 38
Slide 38 text
Laravelのテスト
引用:
https://laravel.com/docs/10.x/testing#main-content
Slide 39
Slide 39 text
Laravelのテスト
UnitTest
● 一つのメソッドに焦点を当てる
● DBや依存ライブラリにアクセスしない
UnitTest
● 一つのメソッドに焦点を当てる
● DBや依存ライブラリにアクセスしない
Feature Test
● APIとしての機能テスト
Slide 40
Slide 40 text
TODOアプリのテスト構成と似ている
E2E
Integration
Unit
Slide 41
Slide 41 text
『単体テストの考え方 / 使い方』のテスト
単体テスト
● 1単位の振る舞いを検証
● 実行時間が短い
● 他のテストから隔離されている
Slide 42
Slide 42 text
1単位とは？？？
Slide 43
Slide 43 text
1単位とは？？？
Contextによって単位が変わる
Slide 44
Slide 44 text
1単位とは？？？
担保したい価値の最小単位
Slide 45
Slide 45 text
定義がないので
チームで話し合って定義してみた
Slide 46
Slide 46 text
Unit
● TODOを作成できる
担保したい価値
Slide 47
Slide 47 text
Unit
● TODOを作成できる
Integration
● TODOを管理（作成・編集・削除）でき
る
担保したい価値
Slide 48
Slide 48 text
● プロダクトとしての機能をテストで担保しよう
● 依存しているブラックボックスも通そう
● 自分たちの1単位は何なのか見直そう
まとめ
Slide 49
Slide 49 text
おわり