測試篇

不要跳過簡單的測試，他們是如此容易撰寫，相較於針對程式的說明價值，所花費的撰寫成本相當便宜。事實上，作者認為足夠的測試，是所有條件或計算都被驗證過，只要有任何可能失敗的條件沒被測試過，這樣的測試就是不足的。

也就是說，要追求涵蓋率盡可能的大。而現今的 IDE 或測試套件，基本上都有提供涵蓋率工具，能幫助我們更直觀、快速地了解目前程式的測試狀況。為了能夠在各個方面都確保程式的健全，我們尤其應該注意邊界條件的測試。我們難免會遇到，一般情形運行良好的程式，卻在遇到邊界情況時會產生錯誤，因此需要特別小心。

讀到這裡，我知道很多人心裡一定會冒出一個疑問：我們真的需要追求涵蓋率嗎？因為測試的高涵蓋率，其實並不能保障程式一定正確。事實上，測試本身並不能證明程式正確，它只能告訴我們，我們目前找不出它有錯誤，所以假設、推斷它正確。

這裡要先說個題外話。雖然內容不是在說單元測試，但在 Uncle Bob 的另一本著作【無瑕的程式碼：整潔的軟體設計與架構篇】中有段話提到：

數學是要證明「可證明陳述是真實的」。相反地，科學是要證明「可證明陳述是虛假的。」

而單元測試，就是用科學的方法，想辦法證明程式是錯的。如果我們用盡各種方法都無法證明它是錯的，那就認定該陳述已經足夠真確。

那麼既然單元測試的高涵蓋率也不能保證程式完全正確，我們是否就可以大略地將測試覆蓋到主要程式就好了呢？我之前所學習到關於測試的概念是：可以。我們確實不要花費太多心力，讓測試盡量覆蓋更多的程式碼。

那為什麼 Uncle Bob 會認為，我們只要有任何一種可能失敗的情形沒有被驗證過，這個測試就不算足夠呢？其一，我認為就是上述所說的，雖然測試無法保證程式正確，但也已足夠讓我們認為真確。就像我們用科學的方法認識這個世界，但實際上我們永遠無法藉由科學認識真理(truth)。其二，作者認為「失敗的模式」及「測試涵蓋率」都可以是某種啟示，而模式這種東西，需要有一定的基數才容易觀察出來，也才能具有可信的價值。

例如，當我們發現所有比八個字元長的測試都失敗了，或是所有傳入參數是浮點數的測試都失敗了，有時僅是去查看測試結果中成功與失敗模式，便能找出解決方案。而這，就是高涵蓋率所帶來的另外一種好處。