PHP 也有 Day #44：先別提測試了，你聽過 TDD 已死了嗎？

Slide 1

Slide 1 text

先別提測試了你聽過 TDD 已死了嗎？

Slide 2

Slide 2 text

教授的一點軼事照片僅供參考，與實際人事物並無關連如有雷同純屬巧合

Slide 3

Slide 3 text

● 什麼是測試驅動開發 ● 測試驅動開發的好處 ● 測試驅動開發的壞處 ● 相關開發方式已死？ ○ BDD ● 結論

Slide 4

Slide 4 text

TDD is Dead, Long Live Testing David Heinemeier Hansson RailsConf 2014-04-23

Slide 5

Slide 5 text

又可以少學一樣東西啦！

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

世界級筆戰（含 DHH，Uncle Bob⋯⋯等人）詳情可參考 91 懶人包

Slide 8

Slide 8 text

什麼是測試驅動開發

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

● 撰寫測試之前不寫功能 ● 不撰寫過多測試 ● 不撰寫過多功能

Slide 11

Slide 11 text

測試驅動開發的好處

Slide 12

Slide 12 text

Clean Code

Slide 13

Slide 13 text

可證偽的程式

Slide 14

Slide 14 text

可證偽的程式每個元件功能都經過測試

Slide 15

Slide 15 text

可證偽的程式每次修正錯誤都經過驗證

Slide 16

Slide 16 text

對自動測試的好處

Slide 17

Slide 17 text

對自動測試的好處避免測試遺漏

Slide 18

Slide 18 text

對自動測試的好處如果仔細來看，也許後寫測試還可以達到較高的覆蓋率。但是事後寫的測試只是一種防守，而先行編寫的測試則是進攻。後寫的測試在深度和捕捉錯誤的靈敏度方面要遜色很多。（The Clean Coder）

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

No content

Slide 26

Slide 26 text

TDD is Dead, Long Live Testing Test-first units leads to an overly complex web of intermediary objects and indirection in order to avoid doing anything that's "slow". Like hitting the database. Or file IO. Or going through the browser to test the whole system.

Slide 27

Slide 27 text

controller fileService logicServices mailService dbService Value Object Value Object

Slide 28

Slide 28 text

controller request serviceMock response (Assert) (Assert)

Slide 29

Slide 29 text

logicService input output serviceMock (Assert) （Value Object mock） Don't mock value objects

Slide 30

Slide 30 text

TDD is Dead, Long Live Testing (Test-first units) It's given birth to some truly horrendous monstrosities of architecture. A dense jungle of service objects, command patterns, and worse.

Slide 31

Slide 31 text

controller logicServices

Slide 32

Slide 32 text

單一職責原則＝每個類別只有一個職責＝每個類別只有一個 public function （Recca 不支持這個觀念）

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

controller logicServices

Slide 35

Slide 35 text

然後

Slide 36

Slide 36 text

logicServiceTests logicServiceMocks

Slide 37

Slide 37 text

如果你常用 command 協助測試

Slide 38

Slide 38 text

Commands

Slide 39

Slide 39 text

看起來 TDD 不好

Slide 40

Slide 40 text

When TDD doesn't work.(Uncle Bob)

Slide 41

Slide 41 text

複式記帳法（double-entry bookkeeping）

Slide 42

Slide 42 text

When TDD doesn't work. ● The physical boundary (bell) ● The layer just in front of that boundary（css） ● The test code itself

Slide 43

Slide 43 text

No content

Slide 44

Slide 44 text

Anti Pattern 11: Treat TDD as a Religion

Slide 45

Slide 45 text

In summary, TDD is a good idea but you don’t have to follow it all the time. If you work in a fortune 500 company, surrounded by business analysts and getting clear specs on what you need to implement, then TDD might be helpful.

Slide 46

Slide 46 text

需求極頻繁更動測試剛寫好需求就變了

Slide 47

Slide 47 text

需求極頻繁更動利用測試來保護需求更動

Slide 48

Slide 48 text

等等，那 BDD 呢？

Slide 49

Slide 49 text

什麼是 BDD ● 行為驅動開發（Behavior-driven development） ● Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.

Slide 50

Slide 50 text

No content

Slide 51

Slide 51 text

composer require --dev behat/behat

Slide 52

Slide 52 text

Gherkin ● 醃黃瓜 ● 描述功能，場景，階段的一種語言

Slide 53

Slide 53 text

Gherkin 範例：購物系統：功能 Feature: Product basket In order to buy products As a customer I need to be able to put interesting products into a basket

Slide 54

Slide 54 text

Gherkin 範例：購物系統：規則 Rules: - VAT is 20% - Delivery for basket under $10 is $3 - Delivery for basket over $10 is $2

Slide 55

Slide 55 text

Gherkin 範例：購物系統：場景 1 Scenario: Buying a single product under $10 Given there is a "Sith Lord Lightsaber", which costs $5 When I add the "Sith Lord Lightsaber" to the basket Then I should have 1 product in the basket And the overall basket price should be $9 （5 * 120% + 3 = 9）

Slide 56

Slide 56 text

商務行為說明／測試程式碼

Slide 57

Slide 57 text

將案例直接當作測試執行 $ vendor/bin/behat 3 scenarios (3 passed) 14 steps (14 passed)

Slide 58

Slide 58 text

和自動測試的關係 ● 沒有自動測試保障的 BDD ○ 無法保證需求行為和程式行為相同！ ○ 你寫你的商務行為，我寫我的程式 ○ 井水不犯河水

Slide 59

Slide 59 text

和 TDD 的關係 ● 你可以先寫測試，然後開發 ● 你可以先寫開發，然後測試 ● 嚴格來說，兩者都符合 BDD 的做法

Slide 60

Slide 60 text

再看一次這段話如果仔細來看，也許後寫測試還可以達到較高的覆蓋率。但是事後寫的測試只是一種防守，而先行編寫的測試則是進攻。後寫的測試在深度和捕捉錯誤的靈敏度方面要遜色很多。（The Clean Coder）

Slide 61

Slide 61 text

有沒有延伸的問題

Slide 62

Slide 62 text

結論

Slide 63

Slide 63 text

可以避免 TDD 容易出現的問題嗎？

Slide 64

Slide 64 text

善用隔離框架 Mockery ● Mockery::mock() ● Mockery::spy() Laravel ● Mail::fake(); ● Queue::fake(); ● Storage::fake();

Slide 65

Slide 65 text

測試金字塔 E2E 整合單元

Slide 66

Slide 66 text

世界上有不需要雙方帳本的交易？

Slide 67

Slide 67 text

產品的生命週期

Slide 68

Slide 68 text

開發團隊的狀況

Slide 69

Slide 69 text

還不會走之前不要學飛

Slide 70

Slide 70 text

極重要核心其他 Trying to get 100% coverage on total code is not recommended.

Slide 71

Slide 71 text

CTM（Codepipes Testing Metrics）名稱簡介標準值通常值 PDWT 撰寫測試的開發人員比例 100% 20% ~ 70% PBCNT 能產生新測試的臭蟲比例 100% 0% ~ 5% PTVB 驗證行為（而非實作）的測試比例 100% 10% PTD 決定性（不會無故出錯）的測試比例 100% 50% ~ 80%

Slide 72

Slide 72 text

測試驅動開發 ≠ 自動測試

Slide 73

Slide 73 text

放棄測試驅動開發 ≠ 不寫自動測試

Slide 74

Slide 74 text

避免已知問題 ● 程式是否粒度過細？ ● E2E／整合／單元測試比例分配是否恰當？ ● 是否有不必要的測試？

Slide 75

Slide 75 text

守破離 ● 大安區懷石料理 ● 學習的三個階段 ○ 守 ■ 遵守指導，熟練基礎教條的內容 ○ 破 ■ 打破規則，知道原本教條的缺失 ○ 離 ■ 脫離規範，不再被教條內容束縛

Slide 76

Slide 76 text

No content

Slide 77

Slide 77 text

選用適合當下場景的工具

Slide 78

Slide 78 text

正確理解現況討論決策

Slide 79

Slide 79 text

No content

Slide 80

Slide 80 text

tl;dr ● 測試驅動開發的好處 ○ 避免自動測試有遺漏 ○ 協助撰寫功能時設計成容易自動測試 ● 拒絕測試驅動開發的理由 ○ 容易寫出過多層次的架構 ○ 容易測試原本不需測試的部分 ○ 更動需求時需多維護測試部分 ● 沒有銀彈 ○ 審慎判斷需求 ○ 不要找藉口或偷懶