我相信蠻多人聽到寫測試，第一個反應是：「什麼？為什麼要寫測試？」再來會說：「測試應該是 QA 要去處理的吧！」但我認為，測試正是開發者必須要自己完成的，他會給開發者帶來三大好處：快速檢測，架構優化，測試程式碼即文件。我們由這三點來討論。
快速檢測
想像你在一個沾黏如地獄般的巨大恐怖 legacy code base 中修改程式碼，改完後你能有多少信心度保證不會破壞其他的功能？我個人的經驗是，非常低。
舉例來說，之前遇到一個案例，龐大的系統中一大部份是有關發送訊息的，但之前的開發者並沒有模組化，邏輯散落各地，到處都有相關的 api 呼叫。有同事為了讓架構能往清晰的路邁進，於是著手修改了訊息相關的底層程式碼。但是他並沒有完整改完所有其他人所寫的呼叫，導致上線後破壞了有關的功能。外加修改後也沒有提供文件，其他人要修改還是得回頭去看他所改的部分。
假設今天一個系統有寫測試的話，只要修改一個小地方，立刻就跑測試，電腦馬上就能診斷出這個修改會不會破壞現有功能，大幅節省後續 debug 的時間！
可能你會說，如果要寫測試，就會增加前期開發的時間。沒錯！這是必然，但我認為這可以看成是一種時間投資，以及買保險的概念。因為後續開發時，測試絕對能幫你節省超過投資的時間成本！雖然寫的時候很繁瑣枯燥，但這是一種負責且安全的開發習慣。
回頭來看一開始提的案例，你可能會問說，那現在這個系統沒有測試，怎麼辦？其實這算是另一門學問，之後會在慢慢探討。這邊簡單說一下策略，就是，沒有辦法，只能逐漸做修改。而且每次修改後，一定要補上修改區域的測試，這樣程式碼才能越來越健康。
架構優化
在設計程式的時候，一定無法避免呼叫外部 api，讀寫 db 等等端到端的操作。如果在測試時我們無法解掉外部依賴，將會造成很大的問題。測試的原則就好像演算數學式，五個輸入我們直接給定四個，調整剩下的一個來看結果是否符合需求。假如過程中需要對外部呼叫 api，最終測試失敗，到底是我們寫的程式出問題，還是外部 api 出問題？在判定上會浪費很多時間，就失去了我們測試的原則。
如果在開發時有良好的架構規劃，把外部 api 呼叫都包裝起來，個別模組化並做到鬆耦合，如此就能在測試的時候把外部 api 相關的模組置換成假的，專注在測試我們寫的程式邏輯，如此即可增加測試的效率。
由於我們為了讓程式可測，模組化程式區塊，實現了鬆耦合，未來如果要修改設計，都能享受到高彈性基礎帶來的好處，因此間接的影響了我們的程式架構，達到優化的目的。
測試程式碼即文件
測試的時候會用各種方式調用我們所寫方法或函數，其實就是一種呼叫範例，告訴未來的開發者怎麼使用這些方法，或是給定什麼參數，方法會有什麼反應。有時看 api 文件可能沒有感覺，從測試程式碼來看，就像是一個個範例，反而能夠快速上手。
這三點就是我身體力行後體會到最重要的概念，希望能夠讓你也開始寫測試。雖然寫測試真的很繁瑣，但是寫習慣後，如果哪天開發時沒有寫，真的會心驚驚的呢！
延伸閱讀
程式架構的重要性
Modular Monoliths 是什麼？可以讓我們從單塊泥球中解放嗎？
封面圖片備註
有了自動化測試，就能夠實現如同汽車生產線一般自動化，有問題的時候電腦就會報錯讓我們知道！
