為什麼要撰寫前端的測試？

在前端發展日益壯大後，我們在專案中往往引入了工程化、模組化的概念，這和數年前前端極度依賴後端渲染以及切圖工作產生了極大的進步，當然這些進步也使得我們的專案變得更加複雜龐大，並且在專案中使用了SPA的應用概念，每個工程的複雜化、程式碼的高複用性要求和前端程式碼模組之間的高內聚低耦合的需求，前端工程中的單元測試流程就顯得很有其必要。 我們需要明確單元測試存在的必要性，這項技術是為了使得我們不僅僅可以通過自定義的測試用例來測試我們已經寫好的功能，更加長久持續的意義在於我們在元件中增刪改操作後可以保證我們原先被測試覆蓋到的功能可以不受影響，這更有利於降低測試人員的壓力，提高測試的效率，可以避免在專案迭代後需要測試人員重新重複測試前幾個版本反覆測試過的功能。並且在專案複雜度過高後，”人肉測試“這種方式更加容易出現疏漏，漏測一些必要的功能或細節。

前端測試的型別

由於前端的特殊性，我們往往不同於後端通過檢測一個方法或模組的輸入和輸出就可以依賴去撰寫一個具有目的性的測試用例。在引入了新式框架Vue、React或Angular後，我們對於元件化的運用越來越多，在改變了元件的狀態後往往會觸發DOM的更新，所以前端因此衍生出兩種測試方式。

• 單元測試 （unit testing） 單元測試對應為白盒測試 首先我們需要明確的是什麼是單元測試？首先我們假設我們的專案是一個SPA專案，也就是說我們的專案中都是由元件來組成的，在這裡提倡的單元測試即為對一個單一的元件進行封閉的測試。為什麼說是一個”封閉“的，是因為我們的元件中可能去呼叫別的工具函式或是會觸發別的元件的顯示和隱藏，在這裡是不在單個測試集合的測試範圍中的，我們所需要測試的只是一個元件中自身的邏輯和DOM的反饋狀態，不需要去考慮別的元件或是工具函式的影響。這樣可以最大程度的降低測試用例的耦合度，使用例專注測試元件中的某個具體的功能。
• E2E測試（end to end） 端到端測試則對應的為黑盒測試，即只測試輸入輸出，不考慮過程狀態的測試方式，在前端中這種測試方式最簡單直白的方式的就是通過一個trigger去觸發一個DOM事件，然後通過斷言判斷頁面中的DOM是否符合預期中的更新，很簡單很粗暴的方式，當然這種編寫的方式相對於單元測試難度也會降低不少，所以在技術足夠成熟並且在團隊足夠強壯時可以交給測試人員去撰寫。

技術選型

• 專案框架： Vue 在專案中選用的為Vue框架，所以這一系列也會以Vue框架為主作為一個切入點，這點在和其他框架的測試用例撰寫上會有一定的出入，所以在Vue中也有一個專用的輔助測試工具為vue-test-unils
  ，這個工具會在接下來的教程中演示。 本系列中會採用最新的vue-cli 3.0來構造整個專案，所以在專案構造中會直接選擇各類的需要框架，所以不會演示具體的外掛的安裝過程。
• 單元測試框架： Jest 在vue-cli 3.0中提供了兩種單元測試選型供我們選擇，一種為mocha + chai組合，另一種為facebook出品的Jest框架，在接下來的單元測試專題中會講解為什麼這裡選用了Jest框架。
• E2E測試框架： Cypress 同樣的在腳手架中也提供了兩種E2E測試所依賴的框架，分別為Nightwatch和Cypress，這裡我們選用更新的Cypress，本系列也會著重講解這款框架API的使用。