為什麼要測試
當這個問題開始的時候，反問一下，為什麼不測試？
在經過許多場的開發活動裡面，提到大家有沒有在自己產品裡面寫測試。很多人反應都是沒有的。更深一層的問下去，就會得到一個答案『沒有時間寫測試』。
今天不討論 TDD, BDD ，而是真正跟大家談一下，『為什麼身為工程師你要寫測試』
沒有時間寫測試
很多人知道測試是怎麼一回事，也知道大概寫測試的方法及工具，最常見的就是把 TDD, BDD, XDD 一直放在嘴上。每天都放在嘴巴上尊敬，很少人開始真正進行測試。甚至也不動手下去寫測試。
而真正得到的答案大多是，『開發就沒時間了，哪有時間寫測試。』的確在開發程式的時候，總是會面臨到時間的壓力，在現實的狀況下，可能開發時間只有兩天到三天，在如此強大的壓力下，怎麼可能會有時間寫測試。
這是我的故事
自己的場景經常是如此，每天都會用 Postman, curl 不斷的去跑一下，發出 request 對於自己寫的程式碼開始進行調適，進行結果測試，當然這段過程並不順遂，總是要花去許多時間才有辦法解決掉問題。
當問題解決之後，『YES！』 ，這問題我解掉了，這時候自己有如聖人般的光環，希望讓大家矚目著我，沒錯，就是我，就在剛剛把事情解決了，經過 QA, PM 的人工檢測後，確定，沒問題。
這真是太好了！確定了我的信心（其實我還蠻厲害的）
…. 時間過後兩個星期。
功能總是需要被調整，功能開始改善，被交付：『之前這段程式是你負責，請你幫忙把這個部分修正，應該很簡單吧！』。
腦中開始回顧之前的程式碼。這兩個星期經歷這麼多事情，我連上一餐吃什麼都忘記了，怎麼可能記得兩週前的程式碼。我開始回頭找之前的 curl 指令還有之前下的 request ，SHIT 。為什麼不見了，怎麼都消失了！？
消失的驗證，只能慢慢的把東西慢慢撿拾回來，第一週，開始進入加班模式，來完成這個『簡單工作』，接下來更是才是真正進入修改程式的正式流程，天啊！我真是太神了，還是把如此困難的使命，完成！
修 A 壞 B，點解！？
前面的故事，自己身上發生過無數次，開始思考著，如何把這些驗證的流程統一，如何把這些驗證的方式一致化。因此才開始面對『統一化驗證流程』，讓團隊開發者一起來加入其中，開始嘗試著寫測試，一開始先進行最小化測試，在自己可以理解範圍內，開始進行測試的程式碼在專案中。
最小化測試
最明瞭的方式，透過 function 的方式，驗證每個 function 執行，回傳回來的 return value 進行驗證。先就這樣的方式開始進行，至少在每次新增的程式我們都是如此的進行。
最小化測試
js
fn = require(“./program")
describe “test function start”, (done) ->
it “test first function”, (done) ->
result = fn.blackbox(“kerker")
result.should.be.string
return done()
最小化實作
js
module.exports.blackbox = (arg) ->
return ...
一開始其實沒有太多感覺，也沒有太多實際面的感受，可是隨著下次，再次，再再次的程式調整之後，我們開始可以感受到測試的好處。
開發與開發溝通的語言
建立這樣一堆 mini test 的狀況下，一開始的確感受不到，也只會覺得是在多寫了一些程式，寫了一些測試的方式。
對於自己，實際上透過不斷累積的狀況下，對於自己來說，重構變得比較簡單，開發只需要再增加測試項目即可，我可以透過 mini test 的驗證下，確定 mini stable 最小可行性的安全網，至少我可以確定傳入的參數，和回傳的結果都是在自己可以控制範圍，而且可以透過不斷疊代反覆驗證後，增加修改，程式伴隨著測試，測試伴隨著程式，會讓自己對於自己的程式更加有信心。
對於跟其他開發者，可以透過測試跟對方說明如何使用自己在實作上的想法，透過 mini test 跟大家說明，這個程式『至少』在這個情境底下，我當時所思考的執行方法應該是如此，讓後續的維護者可以有基本啟始點，容易了解自己當初的想法，也讓對方知道如何維護，也讓開發者知道如何使用。
什麼時候開始測試！？
以前沒有，不代表以後都沒有
寫測試，其實也就是在著一份溝通文件，讓開發者，讓自己在這樣一次功夫下去之後，接下來可以更好維護，可以更簡單了解之前的想法，當歷史留下軌跡，當軌跡越來越多，就會更清楚自己的開發歷程。
如果你在新的專案，建議開始現在就進行 mini test
如果你是在舊的專案，以前的程式，也許我們來不及維護，但是新的開發，後續維護，我們都可以想辦法進行，開始進行『最小化測試』 ，透過不斷，不斷，不斷的疊代，讓整個開發的輪廓可以更為明顯。
身為工程師，一定要寫測試
身為工程師，對於自己的程式碼總是有基本的自信，可是 TMD ，怎麼都會在 QA 的電腦上都會出問題，可是 TMD 當初怎麼都沒有在我電腦上出現這些問題呢！？神了，屢試不爽，可以確定的只有一件事情 ，程式不能到 QA 手上。
大家應該對於這樣的答案，沒有疑慮。可是隨著 open source ，隨著多人加入開發之後，每個人都需要為自己的程式達到基本承諾，為了要實現這件事情，請寫測試。
測試一開始的確會讓人感到失望，也讓人感覺到無力，可是就像養成所有好習慣一樣，如果這件事情是痛苦的，那就表示堅持下去肯定會成長，測試可以讓人感到榮耀，測試可以讓人感到歡愉，測試可以讓人感覺到成就。
當然測試會佔用去開發時間，就本著長時間下來，測試是你的一份安全網，測試也是將問題釐清的好工具。
今天不測試，明天還是要測試。
就算你不寫測試，你的另一半還是會測試。
所以，從今天起，工程師一定要寫『最小化測試』。