
290
| 第十一章
Smith 的整篇文章都值得一讀。你必須記得一個核心概念:雖然單元測試與驗收測試
的覆蓋率可能比較低(例如,與端對端測試相較之下),但單元測試可以驗證作品的意
圖,而驗收測試可以按需求來檢查作品。這代表程式碼的行為,與它和系統其他部分的
互動都是可以驗證的,而且可以在短暫的時間內透過最低限度的協調來完成。例如,只
試著使用端對端測試來驗證部分 app 的一系列邊緣案例可能沒有什麼效果,因為你必須
對相關的資料儲存體進行許多協調,而且每一回合的測試都要花長的時間啟動系統、執
行測試,再卸除所有東西。
建構正確的回饋迴圈
測試可以讓你建立一個回饋迴圈,通知開發者產品是否正常運作。理想的回饋迴圈有這
些屬性:
快速
沒有開發者可以忍受需要等待好幾個小時或好幾天之後,才能知道修改是否成功。
有時不成功的修改(沒有人是完美的)需要讓你運行回饋迴圈多次,快速的回饋迴
圈可實現更快速的修改,如果迴圈夠快,開發者甚至可以先執行測試再 check in 修
改。
可靠
沒有開發者願意花好幾個小時對測試程式進行除錯,然後才發現它只是個不穩定的
測試(flaky test)
1
。不穩定的測試會降低開發者對測試的信任程度,不穩定的測試
通常會被忽略,即使它們真的找到問題了。不穩定的測試也會加入沒必要的延遲:
當開發者懷疑測試失敗可能是假的時,他們的第一反應是再執行它一次,而不是進
行調查。
隔離故障
為了修復 bug,開發者必須找出造成 bug 的那幾行程式。當產品有上百萬行程式
時,bug 可能在任何地方出現,debug