本系列文已重新編排並新增內容出版成冊，若您喜歡透過書籍來閱讀的話，歡迎至天瓏書局下單選購唷！
回顧目前我們經歷過的測試脈絡章節，我們一路上談到了：
為什麼要大費周章提測試脈絡呢？
主要是單純的學習測試程式碼只會讓你學到如何用測試程式碼來測試你的實作，但是有脈絡的學習測試將概念與語法抽離開來，才不會在撰寫測試遇到各種心境上的阻礙，所以我們要先排除心魔，確認測試是對我們有益的，那麼接下來就能放心的學習測試語法了。
而今天要來談談最後一部分，那就是關於撰寫測試程式碼前須知的基本觀念！
談到撰寫測試，不得不提到 Robert Cecil Martin 有本經典的《無瑕的程式碼：敏捷軟體開發技巧守則》，作者在其中針對了程式碼的部分提了很多優良的建議，不論是撰寫程式碼中的命名、函式參數等等做探討，也在實際的案例中做一些討論與重構，最後回顧那些程式碼中的氣味、清理程式碼，一氣呵成。
而其中有一個章節最主要就是在講有關「單元測試」的部分，也就是系列文前言提到「被推坑」的部分，我把裡面的概念結合我的經驗來重新闡述一次：
若帶著單純學習的心態來看待測試程式碼，其實很容易把它當作一項輔助工具在處理，覺得沒有也沒什麼關係，甚至礙手礙腳的，甚至可能覺得還要特地花了不少心力來瞭解它，但這是一體兩面的。
若你把它當作產品中的一部分就會發現，雖然開發時會受到測試程式碼的「限制」，但同時他其實也是在做「守護」產品程式碼這件事情；甚至因為有了「可信賴的測試」，所以當我們在進行「重構」等等調整時也才能更有信心地去處理。
因此只要確保我們在適當的時機加入它，那麼它就能夠帶來可觀的後續效益，而既然他能夠替我們帶來效益，那我們對待測試程式碼的態度其實也應該要同理產品程式碼，可是除了讓測試程式碼如同產品程式碼一樣保持「整潔」與「可讀性」之外，我們還有什麼辦法呢？
對於這個問題 Martin 給了一個撰寫測試碼的優良準則，那就是 F.I.R.S.T 法則。
F.I.R.S.T 法則顧名思義其實就是五個英文單字的縮寫，他們分別是：
簡單來說就是快，因為快才能讓我們快速重複大量地檢驗產品程式碼；這意味著我們在測試程式碼中有可能會遇到要 call API 的情況，那麼我們可以將其隔離並立刻回傳我們預定好的資料來減少等待回應的時間。
如我們上一篇文章所提到的，每個測試案例應該要互相獨立，彼此不受干擾之外，甚至連執行順序上都不會影響到最終結果。
可重複性主要提的就是不論在什麼設備狀況下，應該都要保持著一致的結果，這樣我們才能排除掉其他不必要的原因，專注在發生問題的程式碼上。
測試的最終狀態應該要能夠顯示「通過與否」，而這一部分測試工具或框架都會幫我們處理好，甚至都還有提供額外的 diff 差異讓我們快速查看錯誤的地方。
測試程式碼要盡可能的與產品程式碼同進退，如果測試程式碼落後產品程式碼太多，測試程式碼會越來越難跟上產品程式碼的步調。
而根據對待測試程式碼的心態以及一些前輩給予的優良法則，在撰寫測試程式碼時就能更容易體會到他的魅力。
在概念的部分結束後，接下來我們將專注於如何寫好測試程式碼的語法，而語法這一部分將系統的規劃成下列部分：
同時別忘了明天開始要來利用系列文前面所安裝好的專案啦！
iThome鐵人賽
看影片追技術