原文：Testing Your Frontend Code : Part I (Introduction)
By Gil Tayar
不久前，我的一個朋友開始入坑前端，問我如何測試他寫的應用。在電話上，我告訴她我很難在電話上講清楚，因為這方面要學的東西太多了。我答應她會發給他一些文章來指導她。
當我開啟電腦搜尋了一下，我發現了太多的文章，並且對這些文章的深度很不滿意。我沒有發現一些真正有助於理解的文章（從新人的角度來看）。我沒有發現一個以前端測試為中心，既有理論又有實踐的文章。
所以我決定寫一篇。這是這一系列文章的第一篇，你可以通過下面的連結找到其他的。
為了這篇文章，我還寫了一個小應用-計算器。我會藉此向你展示不同種類的測試。在這裡你可以找到原始碼。
啥是測試
測試，按照我的定義是檢查你應用程式碼是否能夠按照預期執行的程式碼。一些人會把這個叫做TDD，但是TDD（Test-Driven Development or Test-Driven Design）只是測試的一種流派，是指先寫測試用例，然後實現業務邏輯。
坦白講，我不認為先寫還是後寫測試用例有啥關係，只要你寫了足夠多的測試讓你覺得你的線上程式碼沒問題就行了。但是有的人認為這很重要，所以我這裡也提一嘴。
遺憾的是，業界內部充斥著TDD的思想，以至於在業務程式碼旁邊寫用例的行為都沒有一個標準的術語去稱呼。我就叫他開發者測試或者僅僅是純測試吧。你可以看下這個，但我建議你看完我的這個系列的文章後再去看。
為啥要測試
不，我不是想要講為啥要測試，你要是不想測就不測。但是你會對你寫的應用一遍遍地重複手動測試，這太噁心了。想想那些詭異的bug，即使你修復了，仍然會在午夜夢迴的時候縈繞在你心頭。上線變成了一個充滿不確定性和恐懼的工作。
我仍然不會講為啥要測試。
測試的型別
對於學習測試的新手來說，不同的測試型別也會讓人感到困惑。如果你對此做過調研，你可能已經聽過（這裡給出一個不完全的列表）：單元測試、接受度測試、整合測試、端到端測試、元件測試和服務測試。
更糟的事，當有人在談起其中一個術語時，他對此的定義可能會和另一個人不太一樣。
再說一遍，我對起名這件事從來都不在意。我認為測試的型別從來就沒有一個死標準。但我認為所有的測試都在一個區間內部，這個區間一頭是單元測試，另一頭是端到端測試（簡寫為E2E 測試）。
測試區間
我們以最簡單的測試型別——單元測試講起。單元測試，顧名思義，就是測試一個單元的程式碼。但是啥事一個單元呢？這取決你用的語言。它可以是一個函式、模組、包、類，甚至是物件（對於JavaScript和Scala來說）。在JavaScript中，通常是一個類或者模組（對於npm/CommonJS來說模組就是一個檔案）。
單元測試最重要的事這些單元是相互隔離的。所以單測很適合測試演算法、函式（比如一個計算字串中包含多少個字元的函式）或者包含多個方法的類。
這些模組都很適合拆分測試，因為他們不大容易相互依賴。但是加入我要測試的單元依賴另一個單元呢？我們有兩條路可走：兩個一起測，或者去mock另一個。
如果我們把兩個單元一起測，那它還是單元測試嗎？這就是測試區間的問題了。那些純粹主義者會說，這就不是單測了。我會說，我壓根就不在乎。我傾向於叫它單元測試，但是如果有人叫它整合測試，或者雙元測試，我也表示OK。
mock是啥意思呢？我們舉個例子：
exports.writeSumToFile = (a, b, fileSumWriter) => {
const sum = a + b
fileSumWriter(sum)
}
複製程式碼這個（顯然是強行人造例子）單元是一個模組，包含一個writeSumToFile函式，接受兩個數字型別的引數，並把它們的和寫入一個檔案中。
但是注意，這個函式並不負責寫檔案，它使用了另一個單元（fileSumWriter）去完成寫檔案。
為了測試這個單元，我們既可以把真正的fileSunmWriter傳進去，或者mock一下這個函式的實現，也就是說在測試的時候並不會寫檔案。
但我們傳入函式的mock實現時，這個測試就絕對是個單元測試了（即使從最嚴苛的角度看）。但是如果我們把兩個單元放一起測，很多人就會說這不是個單測。
我不在乎怎麼叫它。
所以在這一段，我們有測試一個單元的程式碼。在另一端，我們有E2E測試——對整個應用的測試。E2E會測試所有的東西，測試物件就是你要上線的程式碼。
這就是測試區間的兩端。大部分測試都位於這二者之間——它們逐漸增加測試的範圍，越來越多的程式碼會被測試到，越來越少的程式碼被mock。
有些人把這些處於中間的額測試稱為“整合測試”。但是對於那些TDD信徒，整合測試是不一樣的，我們後來會說到。我將會不嚴謹地把那些比單測多但又不覆蓋全部的測試稱作——整合測試。
那你應該如何分配你的測試比重呢？多數人認為，存在一個測試金字塔。單測最多，整合測試要少得多，E2E測試最少。我們把這個討論留在這個系列的末尾，因為這些文章的重點是要如何做單元測試、整合測試和E2E測試。最後我們會套路測試策略——每個測試你應該寫多少和一些其他需要考慮的事情。
敬請期待下週的第二部分，我會在那兒討論單元測試。