iT邦幫忙

2021 iThome 鐵人賽

DAY 6
1
Software Development

成為乾淨的開發者吧! Clean Code, Clean Coder, Clean Architecture 導讀之旅系列 第 6

Day 06: 測試驅動開發 (Test Driven Development) (持續編輯中 45%... )

「然而,沒有測試套件,他們就喪失確保『程式修改後是否仍能照預期般工作』的能力,他們沒辦法保證『對系統某部分的修改不會搞爛系統其他部分的程式』。所以他們的程式缺陷率開始上升」

「他們開始害怕修改程式,他們的產品程式開始腐壞,最後變成沒有任何測試、混亂和 Bug 叢生的產品程式」

取自: Clean Code (p.140)

CH9: 單元測試 (Unit Test)

關於整潔的測試這個議題,本身就能寫成一本書。測試程式保存和加強了產品程式的:

  • 可擴充彈性 (Extensibility)
  • 可維護性 (Maintainability)
  • 可再利用性 (Reusability)

不只如此,先寫測試程式反而能加快產品開發的速度

作者的朋友 Jason Gorman 以一個將羅馬數字與整數互相轉換的小程式為例,共花了 6 個小階段去開發程式,並故意間隔採用 TDD 開發策略 (即,開發功能前先寫好測試程式):

https://ithelp.ithome.com.tw/upload/images/20210921/20138643cecrm7Xog8.png

取自: Clean Architecture (p.9)

我們從中可以發現:

  • 有採用 TDD 開發策略的日子比非 TDD 日(不寫測試,直接上) 的開發效率平均快上 10%
  • 即使是開發最慢的 TDD 日也比開發最快的非 TDD 日還省時

我們或許可以得到兩個啟發:

測試程式對一個軟體專案的影響程度就跟產品程式一樣重要

想要走的快,唯一的方式就是要走的好

取自: Clean Code (p.150) & Clean Architecture (p.10)

TDD 的三大法則

  • Rule 1: 在撰寫一個單元測試 (測試失敗的單元測試) 前,不可撰寫任何產品程式
  • Rule 2: 只撰寫剛好無法通過的單元測試,不能編譯也算無法通過
  • Rule 3: 只撰寫剛好能通過當前測試失敗的產品程式

讓測試程式整潔

一個測試一次斷言 (Assert)

一個測試一個概念

F.I.R.S.T.

  • Fast
  • Independent
  • Repeatable
  • Self-Validating
  • Timely

P.S. 關於 TDD 的探討在國外也有另一群人批評其為 "Cargo Cult" (邪教),有興趣的讀者們可以自行 Google 查找相關資訊。另外,究竟台灣的職場環境適不適合導入測試驅動開發(或說,該如何說服主管?),筆者挺好奇各位大大們的看法,歡迎交流~


上一篇
Day 05: 物件及資料結構、邊界 (持續編輯中 45%... )
下一篇
Day 07: 類別、Kent Beck's 簡單設計守則 (持續編輯中 38%... )
系列文
成為乾淨的開發者吧! Clean Code, Clean Coder, Clean Architecture 導讀之旅31

尚未有邦友留言

立即登入留言