前言

一直想要研究「如何寫好 JavaScript 測試」，但過了好一段時間卻遲遲還未開始，決定透過報名 2020 鐵人賽，迫使自己選定這個主題專注學習。對我來說，學習只有單純吸收是不夠的，如果可以把吸收進來的內容，透過實作、內化，產出學習紀錄，會是一個比較深刻的學習經驗。

我沒有在實務上寫過測試，目前工作上開發的專案也沒有引入測試，正是個準備入門測試的新手。希望自己的學習可以循序漸進從觀念的建立開始，先理解為什麼要做、要做什麼，再到如何實作。

此系列的內容主要是 Testing Javascript with Kent C. Dodds 課程的學習心得與整理，文章的編排脈絡基本上就是參照課程的學習內容，但文章中會避免使用到課程的材料。

這是我第一次參加鐵人賽，志在參加不在得獎。這次參賽的目標只求達成一個對自己的承諾：循序漸進且不要中斷地在這三十天好好完成課程。發表文章算是在幫自己的學習做個整理。也希望有機會能逐步在工作上導入測試。

現在，立馬，讓我們從零開始一起學習吧！

2021 年 9 月更新：這系列後期文章，其實每天都在臨時抱佛腳發文，學習筆記整理地有點混。但還是有些好心人訂閱了這個系列，近期希望可以好好來把這系列的內容整理地完整一點，順便做一些內容的更新，才能好好與人分享。另外，必須再重申：這系列是學習 Testing Javascript with Kent C. Dodds 這門線上課程後的整理，對於任何想學習更多關於 JavaScript 測試的人，非常推薦可以買入這門課程。

四種測試的類型

首先，大致上有四種類型的測試，可以幫助我們維持高品質的程式碼。

靜態檢查 (Static)

幫助捕捉錯字或是型別錯誤。

單元測試 (Unit)

驗證單一功能或可獨立的部分，是否符合預期的結果。

整合測試 (Integration)

驗證一系列相關的功能，是否和諧運作無誤。

端對端(End to End)

直接模擬使用者的操作，驗證功能符合預期的行為。

有時又稱為功能測試 (Functional testing)。

為什麼要寫測試

常常改了 A 功能卻壞了 B 功能？

在開發的時候，我們可能都有過一個經驗，那就是原本只是想修改 A 功能，寫完之後卻發現，專案好像有其他地方變得怪怪的，原本可以好好運作的 B 功能卻壞了。這時候，你可能得回頭修復 B 功能，等手動驗證完所有功能都正常後，半天或一天就過去了。如果只是發生在開發階段，那折損的就是這些瞎忙的時間，但若是已經交付到正式環境，才被使用者發現的話，還真的不是樂見的情況。

重構後要花很多時間驗證結果與重構前一致

好不容易心血來潮，想到來重構一下舊的程式碼，結果要花好一番功夫手動驗證重構後的結果與重構前一致，或是重構後發現功能壞了，這時候，只好選擇以後都不要重構好了（誤 XD。

測試，就是幫助我們避免上面的情境一再發生。讓測試來自動化那些原本需要反覆手動驗證的步驟，告訴我們改動之後，專案的程式碼是不是牢靠的，確保我們真正將心思專注在開發上面。

你可能開始產生疑問：到底哪來那麼多時間寫測試？

沒錯，在工作上，我們總是必須在有限的時間內交付產品，對於開發者來說，往往不會覺得時間夠用。不過，我們花一點時間寫測試，就是為了解決無謂的時間耗損這問題，而提高效率。另外，造成「沒有時間」這個結果，可能也跟團隊開發流程、需求溝通、開發者個人技術有關係，不過這就不在這系列的討論範圍裡，這系列會專注在學習：如何寫測試、如何把測試寫好，降低在專案中導入測試的成本。

最後，在寫測試前，我們還需要學會的思考是：

• 應該測試什麼？
• 什麼時候應該寫測試？
• 100% 的測試覆蓋率是必要的嗎？多少的測試才是足夠的？