前端測試：Part1 （介紹）

原文：Testing Your Frontend Code : Part I (Introduction)

By Gil Tayar

不久前，個人一個朋友開始入坑前端，問我如何測試他寫的應用。在電話上，我告訴她我很難在電話上講清楚，由於這方面要學的東西太多了。我答應她會發給他一些文章來指導她。

當我打開電腦搜索了一下，我發現了太多的文章，而且對這些文章的深度很不滿意。我沒有發現一些真正有助於理解的文章（重新人的角度來看）。我沒有發現一個之前端測試爲中心，既有理論又有實踐的文章。

因此我決定寫一篇。這是這一系列文章的第一篇，你能夠經過下面的連接找到其餘的。

• 介紹
• 單元測試
• E2E測試
• 集成測試

爲了這篇文章，我還寫了一個小應用-計算器。我會藉此向你展現不一樣種類的測試。在這裏你能夠找到源碼。

啥是測試

測試，按照個人定義是檢查你應用代碼是否可以按照預期運行的代碼。一些人會把這個叫作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測試。最後咱們會套路測試策略——每一個測試你應該寫多少和一些其餘須要考慮的事情。

敬請期待下週的第二部分，我會在那兒討論單元測試。