[Comments] 測試覆蓋率與 TDD 的正確心態

許多公司往往為了 KPI 需要數字,所以將測試覆蓋率訂了個 criteria 來「強暴」開發團隊,甚至要求團隊「一定」要用 TDD 來開發所有程式。

這一切都是不求甚解的為了潮、為了追求數字的迷思,本篇文章將補上我對於「測試覆蓋率」與「看待 TDD 的正確角度」的見解。

前言

在微信與 Facebook 上看到大家轉發的一篇文章:100%代码覆盖率的悲剧。我剛好從這篇文章,來對測試覆蓋率TDD 做一些補充。

先來個總綱:「一切的目標都是為了寫出好讀、好維護、好設計的產品代碼。」

有了目標我們再來看別的東西,就清楚多了。

WHY TDD?

如果你不知道怎麼簡單設計,TDD 可以幫助你,但你不一定非得要用它。

如果你不知道怎麼設計出讓呼叫端易用的 API,那 TDD 可以幫助你,但你不一定非得用它。

如果你想要讓測試案例被自動化生成文件,你應該先問一下,你產生出來的文件效益在哪,如果沒有,那你不一定需要它。

CODE COVERAGE CRITERIA?

針對 code coverage 的部分,如我在培訓課程上提到的,在團隊中若真要給個 criteria,我會建議測試覆蓋率至少 > 0%,也就是應該要有測試。這原因是,讓後續的人只需要加測試案例即可,不需要自己建測試專案、拉參考、設定 CI config,後手的人不用從無到有,只需要新增測試程式就好,這樣就會減少很多心裡的抗拒

接著要求的重點在於「相對趨勢 > 絕對數字」,與其去訂一個覆蓋率 > 20 %, 還不如定義,每次 build 之後,coverage 只能比原本的高,這意義是對自己這次簽入的程式碼負責。(無須對前人的 legacy code 負責)

接著鼓勵大家頻繁簽入,整體程式碼的覆蓋率就會不斷提昇。

這就是 Uncle Bob 所提的童子軍法則:讓離開時的營地比原本更乾淨。

Code Coverage 的比例向來不是重點,有數字時大家就只會迷思在數字,這是 KPI 思維,不是 OKR。

要去調研的應該是:「那些沒被覆蓋到的產品代碼,發生什麼事了?」

有需求存在,但漏了測試案例?它重要嗎?值得補嗎?

還是根本需求已經不存在,這只是段 legacy code, 這段產品代碼根本沒有存在的必要了。那就清掉它。

這才是看待測試覆蓋率的正確方式。

結論

  1. 測試覆蓋率的數字不是重點,辨識哪一些代碼沒被測試覆蓋到,所代表的意義才是重點。
  2. 相對趨勢 > 絕對數字,每個人願意為自己的部分負責(就像擦自己屁股總是甘願一點,擦別人屁股總覺得髒),測試覆蓋率只能往上提昇,不能往下掉,接著鼓勵頻繁簽入。
  3. TDD 是種手段,是達成目的的一種很好用、很值得投資的方式,把 TDD 當作達成目的的一種方式,而不是把 TDD 當作目標。嚴格來說,TDD 是一個好的開發習慣。
測試,對軟體開發來說,一直以來都是剛好順便、一氣呵成的輔助而已,從來都不該是目的。
【補充】上次跟曉梅老師交流了一下開發人員的測試,與測試人員的測試,其實壓根就只是同名不等義。開發人員的測試,應該稱做 CHECKING,而測試人員的測試,才稱做 TESTING。因為開發人員的測試,是針對已知的輪廓、期望進行驗證。測試人員則是探索著產品跟功能未知的部分。 

對敏捷開發有興趣的朋友,可以參考我的粉絲專頁:91敏捷開發之路

對 TDD 課程有興趣的朋友,課程內容、大綱與學員心得,可以參考 skilltree 的公開課程:自動測試與 TDD 實務開發

若需要聯絡我,可以透過粉絲專頁私訊或是側欄的關於我。