為啥開發人員都覺得 TDD 好,卻又覺得在實務上有些彆扭,也有很多說法把它講得有些不切實際、太理想化呢?
你以為它是測試,但其實在它的本質上,同時兼具了「Specification」與「Test」兩種維度的身份。
隨筆記錄下來想法,這個「測試驅動開發」的「測試」,可能跟你想得不一樣。
為啥開發人員都覺得 TDD 好,卻又覺得在實務上有些彆扭,也有很多說法把它講得有些不切實際、太理想化呢?
你以為它是測試,但其實在它的本質上,同時兼具了「Specification」與「Test」兩種維度的身份。
隨筆記錄下來想法,這個「測試驅動開發」的「測試」,可能跟你想得不一樣。
許多公司往往為了 KPI 需要數字,所以將測試覆蓋率訂了個 criteria 來「強暴」開發團隊,甚至要求團隊「一定」要用 TDD 來開發所有程式。
這一切都是不求甚解的為了潮、為了追求數字的迷思,本篇文章將補上我對於「測試覆蓋率」與「看待 TDD 的正確角度」的見解。
學會 TDD?用 TDD?落實 TDD?到底什麼時候該用 TDD 呢?
TDD 其實是一種修煉的過程,讓你可以在每一次寫程式的過程,都逐步在累積功力,就像金庸的射雕英雄傳中,馬鈺教郭靖修煉內功的方式,無外乎就是一些呼吸、走路、睡覺的法子。
什麼是 legacy code? 沒有自動測試保護的就是 legacy code 。
-Michael Feathers, 《Working Effectively with Legacy Code》
講直白一點,legacy code 就是沒爹沒娘沒靠山,被人射後不理的產物。
誰都可能欺負它、弄壞它,簡直就是一直像死了般卻仍在線上活著的產品程式碼。
為什麼要透過 The Three Laws of TDD 來限制 TDD 的過程,這近乎於不合理的三條限制法則,能帶來什麼好處?
TDD 是一種限制的美學。
[懶人包]DHH: TDD is dead. Long live testing. 懶人包整理