今天就書中描述與我個人的開發經驗，來談談該如何撰寫測試吧。有時候我們可能會遇到，軟體在開發之初並沒有做測試的打算，可能有各種原因，包括時程的壓力、只是想快速驗證原型等等...但若是專案打算要長期發展的話，缺乏測試勢必會造成穩定性逐漸下降，而導致之後難以開發（我在學校參與的某個專案就是如此，中期受不了了便停下開發來寫測試）。

我認為區分程式碼的重要性會是首要步驟，我們可以透過檢視專案當中的各個模組，去比較他們對於使用者的影響會有多大，有的地方出了點 bug 或許無傷大雅，但是某些地方若是引入了 bug 可能會造成難以承受的後果。在著手撰寫測試之前，先做好這些排序可以幫助我們更快的感受到測試帶來的效益，進而提升撰寫測試的動力。

接下來，我想可以先從簡單的步驟開始做起，這部分或許跟上個步驟有些衝突，因為測試重要的部分可能需要耗費大量的精力，但其實有些簡單的檢查或許就可以避免不少麻煩，像是如果是使用 typescript 的專案，若是可以在 CI 的流程裡面先跑一下 tsc，至少就可以幫我們抓出一些型別錯誤，然後程式碼的 linting 與排版也是，可以確保提交的程式碼採用一致的風格，減少 PR 裡面引入無謂的變更，讓 reviewer 可以關注真正重要的部分。這些都是我認為可以透過較低的投入產生較高效益的行為。

最後一點，替每個 bug 都建立相對應的測試。若是有做到，我想可以避免將來出現需要一次撰寫大量測試的情形，而且我們可以確保撰寫出來的測試案例是真的有解決問題的，不會僅僅是自行推測可能會出現的問題。長期下來，便能建構完善的迴歸測試，避免犯下與過去一樣的錯誤，也能逐漸完善測試的覆蓋範圍。