學習要點

要能快速的重現錯誤，才有可能快速的開發跟修復。

故事描述

老實說，我是在「第三次」接觸到寫測試是開發的部分這個觀念，才真正打從心裡接受，並重視它的。因此我很能理解那些對測試排斥的人。

雖然說第二次知道它時，團隊真的有開始局部的使用，但是當時我負責的任務，大多是對現有功能進行小修改，或開發丟棄式的行銷活動頁。這樣的任務對是否寫測試程式，並沒有太大的必要，所以當時我對導入過程的重重困難留下深刻印象，但實際上並沒有親自寫過測試。

直到第三次，我接受了一份自動化測試軟體工程師的工作，人生就是這麼神奇，印證了墨菲定律。過去從未寫過測試程式，結果這次卻讓測試成為我的主要職責。無藉口也無法逃避，只能正面迎擊。

初期花了很多時間研究如何寫測試，隨著研究的深入，我才發現，過去在軟體開發中的做法實在錯得離譜。一天工作八個小時都在寫測試，讓我對於如何撰寫測試程式，有深刻體會，並漸漸認同與落實「測試驅動開發」思維。

啟發

會排斥寫測試程式，通常可以歸類兩種情況：

1. 寫測試的技能不夠熟練，寫的速度很慢，自然就會覺的寫測試很花時間，所以懶得寫。

2. codebase 不利於寫程式

當你工作越久後會發現，修 Bug 的時間往往比開發新功能多。而寫測試能讓你更快找到錯誤，並快速驗證修復是否正確，這是十倍工程師的秘密武器。

理論：測試驅動開發

測試驅動開發 (Test-Driven Development, TDD) 是一種軟體開發方法，要求先寫測試，再撰寫最少的程式碼來通過測試。這種方式有助於開發者將程式切割成可測試的小部分，並確保程式符合測試要求。

實踐指南

什麼情況下 codebase 會不利於寫程式呢？可以從寫測試程式，需要哪些條件因素得知。

1. codebase 要分 dev mode 跟 test mode

   • 測試資料必須在每次測試後清空，避免影響下一次測試結果。

2. 測試程式需要大量的假資料進行模擬

   • 以付款功能的測試為例，你需假設至少能獲取 User 和 Order 資料。如果這些資料不存在，那麼在撰寫付款功能測試前，還得先準備這些資料，這無疑增加了測試撰寫的難度與所需時間。

3. 要測試的程式邏輯是單純的純函數，依賴輸入與輸出，沒有外部依賴。（下一篇會做更詳細的介紹）