測試計畫

在 Facebook，我們使用 Phabricator 審查和討論程式碼的每一項變更。我認為它比 GitHub 的拉取請求（Pull Request）模型更有優勢。本文我想探討其中一個優勢：必填的「測試計畫」欄位。

一開始，我對這個欄位感到很困惑，撰寫測試計畫時不是花太多時間就是太少。隨著時間推移，我漸漸體會到它的價值，並找到一些策略讓它發揮極大效用。

Phabricator 的 Differential 產品以修訂版（Revision）為單位運作。修訂版是指對程式碼庫做出有意義的變更，例如新增功能或修復錯誤。參考 D16507 作為範例。每個修訂版都有一些相關資訊。測試計畫只是修訂版上的另一個欄位，作者需要在裡面描述該如何測試他所撰寫的功能。

你可能會問，為什麼不直接使用單元測試就好？我們不是應該要有 100% 的測試覆蓋率嗎？可惜的是，現實世界並非完美。

首先，撰寫測試計畫能幫助你發現邊緣案例，並從外部使用者的角度思考你的功能。這也有助於審閱者在實際檢視程式碼變更前，就先找出程式碼中潛在的缺陷。

撰寫測試計畫時，我通常會遵循以下步驟：

1. 檢視你新增的功能，並定義可能的案例。例如：「使用者尚未設定此功能」、「使用者已正確設定此功能」。
2. 思考每個案例允許多少種變化。在第一個案例中，不設定新功能只有一種方式，這可能是大多數人的情況。請確保程式碼在新功能未設定的情況下不會出錯。在第二個案例中，設定可能是正確的或錯誤的。這是再次檢查錯誤訊息的好機會。
3. 寫下這些案例和預期的結果，然後實際執行。很容易落入假設的陷阱。「只是一行程式碼的變更，能出什麼問題？」我再怎麼強調也不為過，藉由思考測試計畫，我發現了多少自己程式碼中的錯誤。而透過執行自己的測試計畫，我發現了更多錯誤。

如果其他人或未來的你想修改這段程式碼，他們可以查看提交訊息中的測試計畫並依步驟執行，即使他們不太了解這個功能及其運作方式。

測試計畫看似只適用於大型程式碼庫，但即使在個人專案中也有許多好處。我發現，撰寫測試計畫的習慣改變了我思考程式碼變更的方式。除非我已經想好測試方法，否則程式碼提交才算「完成」。