支撐京東首頁的秘密：為什麼要進行前端測試？

應用程序上線之前如何進行有效的測試?今年的JAX London大會Gil Tayar向初學者介紹了前端測試的方法以及為什麼測試碼不可選的原因。以下是關於他對大會內容的部分介紹。

Gil Tayar：我的一位朋友曾經問我，前端測試到底應該怎樣做。為了更加系統全面的回答他這個問題，我在網上查閱了大量的資料，但是卻發現這些方法理論卻差強人意，至少在我看來，這些方法的深度還遠遠不夠。從前端測試新手的角度，我找不到全面指導前端測試指南的應用程序，更別說理論和實踐的結合了，所以我決定自己來做這件事。

首先，什麼是測試?

測試的含義在我看來就是你在APP中寫的檢測代碼，也被稱為「生產代碼」，它是按照預期工作的。也有人稱之為「TDD」，但」 TDD」 一般指的是具體的測試方法。

其實不管在編程之前寫代碼還是之後這都無關緊要，只要你寫出足夠的測試能夠讓你的APP正常運行這就可以了。但令人悲哀的是，很多人都覺得這一點也不重要。

現在軟體測試行業已經將測試與TDD相結合，因此程序員和生產代碼一起編寫代碼沒有標準術語。我稱軟體測試為「開發者測試」，或者你也可以這樣理解，軟體測試就是普通的測試而已。

為什麼要測試?

其實測試沒有什麼必須的理由。如果你真的不想測試，肯定也沒人強迫你。假如一次又一次的網頁測試讓你越來越煩躁，那就沒有測試的必要。但是，如果你不測試，有些潛在的bug可能會在未來的時間裡一次又一次的困擾你，從部署到生產都將會是一個噩夢。

測試類型有哪些?

對於初學者而言，剛開始研究各種類型測試的時候非常抓狂。你可能聽過幾個軟體測試大概的類別：單元測試、驗收測試、集成測試、端到端測試、組件測試以及服務測試。

更讓人哭笑不得的是，假如一群軟體測試的人在一起頭腦風暴，他們對軟體測試中的術語定義可能都不一樣。

但對我而言不太在乎使用哪個術語，因為我認為測試類型沒有硬性定義。在我看來，所有的測試其實都在一個頻譜範圍內。

測試類型的範圍是什麼?

我們從最簡單的類型——單元測試開始。從定義來看，所謂單元測試就是測試「單位」的代碼，那什麼是單位呢?這就取決於你使用的編程語言了。單位可以是一個函數，一個模塊，一個包，一個類，甚至是一個對象(相對於JavaScript和Scala這樣的語言)。舉個例子，在JavaScript中，單元通常就是指一個類或者一個模塊。

重要的是這個單元要進行隔離測試，這些演算法、功能就像一個函數、計算字元串中的字元數或者具有一組驗證函數的類，這是非常完美的。

隔離測試還是比較容易的，因為單元與單元之間沒有依賴性。但我如何知道一個單元和另一個單元是否依賴呢?兩種方法：要麼對兩個單元同時測試，要麼模擬另一個單元。

那麼問題來了，如果我同時測量兩個單元，還能稱為「單元測試」嗎?有些人會不再將它稱為單元測試。但是我仍傾向於叫做「單元測試」。但是如果有人叫做「集成測試」或者「兩單元測試」，那我沒有任何意見。

舉個例子：

這個單元是一個具有writeSumToFile功能的模塊，它接受兩個數字並且可以將他們直接寫入文件中。

但是值得注意的是，它本身並沒有被寫出來。它使用另一個單元fileSumWriter來編寫。為了測試這個單元，我們可以通過實際的文件編輯器或創建一個模擬來實現。

從最純粹的意義上講，如果將mock傳遞給函數，無疑這個測試就是一個單元測試。但是當它們一起測試時，很多人就會認為這不是單元測試。

其實這都無關緊要。一方面，我們有代碼測試一個單位。另一方面，有E2E測試——整個應用的測試。一切測試都在E2E中進行，並且APP運行時會在與生產系統類似的環境中運行。

這代表著兩個極端點——它們定義了越來越大的測試範圍，在這個範圍內，越來越多的代碼被測試。

有些人稱這些測試為處於「集成測試」之間的測試，但對於TDD-ers，集成測試意味著一個完全不同的東西。集成測試確切的說即使測試超過了一個單元但不包括所有的單元。

大多數人都認為有一個測試金字塔——其中包括許多單元測試、較少的集成測試以及少量的E2E測試。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！