Gerard Meszaros
測試是為誰寫的？#
你正在為部分或全部的生產程式碼撰寫自動化測試——恭喜！但你寫的是好的測試嗎？判斷方法之一是問自己：「我為誰寫這些測試？」
如果答案是「為了幫我省下修 bug 的力氣」或「為了讓編譯器能執行」，那你很可能沒有在寫最好的測試。
你應該為試圖理解你程式碼的人寫測試。好的測試就是程式碼的文件，描述程式碼如何運作。
好測試的三個要素#
對於每個使用情境（usage scenario），測試應該：
- 描述前置條件（context）：必須滿足的起始點或前提
- 展示軟體如何被呼叫（invocation）
- 描述預期結果（postconditions）：需要驗證的預期結果或後置條件
不同的使用情境會有這三個部分的不同版本。讀者應該能透過比較幾個測試中的這三個部分，就能看出什麼導致了軟體的不同行為。每個測試都應清楚展示這三個部分之間的因果關係。
可讀性是關鍵#
測試中看不見的東西和看得見的一樣重要：
- 過多的程式碼會用不重要的瑣事分散讀者注意力
- 盡可能用 Extract Method 重構，將瑣事隱藏在有意義的方法呼叫後面
- 給每個測試一個有意義的名稱，描述特定的使用情境，讓讀者不需逆向工程就能理解
- 測試類別和方法的名稱應包含至少起始點和呼叫方式的資訊
- 方法名稱中也可以包含預期結果（但不要讓名稱太長）
驗證你的測試#
測試你的測試：在生產程式碼中故意插入錯誤，驗證測試能否偵測到並以有意義的方式回報錯誤。同時，讓不熟悉你程式碼的人閱讀你的測試，聽聽他們學到了什麼。如果他們無法清楚理解某些東西，問題可能不在他們——而是你的測試不夠清晰。