這篇其實不僅僅針對「前端工程師」，而是開發上寫「測試」這件事情，都應該從你我做起，寫測試是在保護我們的程式。
標題上使用「前端工程師」，是因為會用 JS 來表示，大家可能比較熟悉，還有測試一下 medium 的「SEO」。
只看文字耳邊可能太無聊，邊聽首歌，邊看吧！
如果你已經在寫測試了，那肯定已經體會到「測試」所帶來的美好世界，但如果你還沒有接觸過或是正要「考慮」是否要寫測試，那你可以聽聽我這一路過來的經驗，本篇以論述為主不會有特別程式碼，請放心。
Ａ：「現在在專案上一定不能沒有測試，就算只有我一個人，還是會乖乖把測試寫好」
Ｂ：「為什麼？你只有一個人，還要寫測試？」
首先在開始進入寫測試的階段時，肯定是看了一些文章或是聽了某些前輩開發者的建議，聽到了很多好像很棒的好處，於是下定決心開始好好研究測試一番，於是查了查網路上的資料，看到了類似的以下範例（僅示例）：
然後跑了一下測試指令：
npm run test哇賽！竟然 pass 了，於是開始覺得自己有了寫測試的能力，就開始繼續嘗試添加更多的內容：
到了這裡其實也順便把測試這個「事情」給體現出來了。
於是體會到，「原來是要確定程式預期結果是正確的！」
沒錯，你抓到了測試這門學問其中「一小部分」的精髓了，你很疑惑為什麼會是「一小部分」，不就是確定是否正確嗎？
於是我們寫了一個打印 log 用的 function
沒錯，畫面上出現了 HelloWorld，那這樣一來不就能夠確定我的 HelloWorld 是沒有錯的了嗎？這就是我們想要的「預期結果」。
於是到了最後漸漸很多人開始覺得
「測試」好像沒有這麼必須？
「測試」好像讓我的工時變得更長了？
「測試」都在寫一樣的東西
「測試」我寫的東西都一極棒，每次都很小心翼翼，是要做什麼測試啦！
「測試」…. 坑
然後..然後..然後，就放棄了。
其實我自己在以前有很多次都是這樣而放棄了，我也相同遇過也有相同的想法，但我們必須學著改變，為了彼此都好。
測試困境
往往開始執行測試時，會遇到幾個問題
- 測試到底要從什麼開始？該測試什麼？
- 聽說測試要花更多的時間寫程式？
- 測試真的好煩哦，我不就只是要結果正確就好嗎？
- 公司沒有這個體制，推不動！
從「1 ~ 3」這三點來講，可以綜合一起來說
到底什麼時候該測試？測試要花好多時間喔！
現在我告訴自己「不是任何程式碼都需要寫測試」
這也是我一開始很疑惑的地方，到底測試要測試什麼？我是不是寫了一個方法甚至一個元件，我就必須要寫測試，這樣我不就等於在開發兩項重複的專案？
等等等，到這裡我們要慢下腳步想一想，回到標題所說的，測試是在「保護我們的程式」。
首先測試前我會先做評估，評估什麼？
評估「這段程式碼的重要性」
如何判斷重要性？
這個必須要有長期的經驗，例如有一個方法，必須要能夠很強迫限制各種參數的類型，不能有其他誤傳的狀況，那就可以把它列為必需要測試
為什麼要測試？
因為可能我們在改動方法內部的變數時，不小心的更動到了某個變數值，而導致結果不正確，而在測試上，我們就能針對所有預期可被接受的值，來去做個別測試，這麼一來，就能夠安心的隨意改動我們的程式
因為只要「沒有全部通過」，就是寫錯了程式碼。
所以我並不會把任何的程式碼都寫上「測試」這件事情，而是經過篩選後，才正式開始從測試寫起，並且記得
「先寫測試，再寫實踐」，而我也這麼推薦
這麼一來的好處，我們不會把結果拿來寫測試，因為當一個方法還沒有被實踐時，我們只會預期結果，不會在意方法裡面有什麼判斷，因此可以讓我們的測試結果更精確，並再次強調
因為最後「如果測試不過，就是方法有問題！」
因此，測試除了預期正確性以外，再來是要保護我們的程式碼，讓我們可以在重構某個方法的時候，可以安安心心地重構，不怕任何失手的事情發生，尤其在共同開發的時候，有測試都是在保護彼此程式的正確性。
再來就是測試雖然會花 1.5 到兩倍的開發時間，但卻可以對我們的未來減少兩倍的維護成本，從長期經驗下來，其實最後都是因為維護困難，而使開發時程拉得更長，從前面的多兩倍時間，也許最後得到的不止有省兩倍的維護成本，而是降了四倍、六倍的成本也說不定，這確實是可以量化的。
來個活生生的例子
前陣子跟我夥伴在做開發時，我們要實作一個做「是否有重複值」判斷的方法，首先我們用兩種方式一個先用純原生方法來寫（因為要先上），另一個是用 ramda 來寫（想要寫的更簡潔漂亮），而我們透過「測試」來撰寫我們的預期結果，一開始先使用純原生方法來繼續開發，之後夥伴寫完以後，測試一過，立馬把方法替換上另一個方法。
「因為有測試，因此我能夠相信肯定是一個對的方法」
於是這個方式屢試不爽，每次就是乖乖寫測試，再替換上重構後的方法，真的是一極棒！
你有點感受到好處了嗎？
一份程式碼一個方法，不用再這麼依賴一個人來撰寫與維護，只要有了測試，誰來重構程式碼都一樣，只要測試預期做的夠足夠，肯定是不會有任何瑕疵出現，會有瑕疵，那就是測試的質量不夠。
更快得知結果
這是什麼意思？意思是，有時候我們必須要透過呼叫了方法以後，丟入正確的參數值，才能正確使用方法，取得結果，如果有了測試，我們就不必要再做這麼複雜的手續，通過觀察測試就可以立即知道這個方法是要做什麼事情，而結果會是什麼，這也會很快減少一個溝通與閱讀的成本。
公司推不動
其實我覺得是這樣的，因為在產品的開發週期都很短，大家都想要趕快完成事情，而本身能夠熟悉且足以快速寫完測試的開發者可能也不見得在同一間公司是大多數，所以很多時候會因為「時間」而放棄，這確實沒有太好的方法可以解決，只能試圖從自己下手，慢慢讓整個開發團隊看到好處（就像我現在正在做的事情），嘗過了一兩次寫測試的甜頭後，漸漸大家就比較能夠接受，而撰寫測試的快慢還是得取決於經驗與規格的詳細，因此這部分是需要經過時間的淬煉，每天開始寫一點測試，慢慢的把測試寫到很自然，那也自然而然就會加速整個開發的時間，而不至於因為寫測試而讓整個開發週期變得很長。
如何增加撰寫測試的速度？
寫！
最後
「寫測試，只能從你我做起，為了讓彼此有更好的開發環境」。
我是懷恩，目前是一位 YOSGO 的核心開發，在一個我熱愛的新創團隊活躍著，是個全職的全端開發者，我熱愛開發與分享「前端專注在瀏覽器的相關開發、效能與互動體驗」
「後端專注在網頁伺服器的效能調適與架構的配置」
「對於網頁技術有著熱衷，隨時跟在新技術的旁邊」目前正在努力推廣「測試」與「強型別（TypeScript）」的使用
如果您覺得文章有幫助到您，請不吝嗇給我一個手掌
讓我們做一個「Give me five」然後就繼續一起往更美好的開發大道前進吧如果您有任何問題，歡迎與我聯繫，我也時常在自己 FB 上開直播做紀錄
Github: https://github.com/madeinfree
FB：https://www.facebook.com/haowei.liou
Email: sal95610@gmail.com
