End-to-End test 是也可以被寫成 e2e test，相對於 unit test 或是 integration test 者種測試每一個邏輯的測試， e2e test 他是以模擬使用者的使用流程來測試整個產品在流程中的所有表面是否出現任何和我們預想的不一樣的狀況出現，而且如果在流程中有使用到第三方的 library 或是有打 api 都不能使用假資料，而是必須要實際去執行，這樣才能確保整個程式測試出來的結果是正確的！
例如今天我們開了一間飲料自動販賣機，裡面其中一個品項是 30 塊錢的珍珠奶茶。此時 e2e test 就會模擬使用者拿 30 塊錢投入這台自動販賣機並且選擇珍珠奶茶之後就會期望可以得到一杯珍珠奶茶，之後當我們得到這杯飲料的時候如果他是珍珠奶茶代表可以測試「通過」，如果得到其他東西或是根本沒有得到就是測試「不通過」。
在現在所有產品都變得越來越龐大的情況下，很容易會出現更改一個邏輯之後不小心影響到其他邏輯的狀況，此時 e2e test 因為會模仿使用者的使用行為所以可以作為最後一道防線，防止產品上線之後才出現錯誤。
End-to-End Test 的優缺點
這樣看起來好像 e2e test 真的很好，不只測試範圍大，而且結果又真實，加上還可以幫忙測試 api 有沒有問題，那就只需要 e2e 就好了啊！好像就不需要其他測試了吧！但其實不是這樣的，其實 e2e test 也是有一些沒那麼好的地方的，下面我幫大家整理了一些 e2e test 的優缺點：
優點
- 每一個測試的涵蓋範圍都相對廣
- 測試結果和使用者真實使用結果相同
- 如果是 api 或是 library 出問題也可以測試的出來
缺點
- 撰寫起來複雜且花時間：因為每個測試都必須要涵蓋到一整個使用流程，所以寫起來一定是比其他種測試還又複雜且要花更多時間，也因為這樣，所以會需要更頻繁地隨著程式碼的更新而更新測試。
- 每次在跑都需要相對長的時間：因為模仿了使用者流程，所以就必須要從最一開始來做，例如有 500 個測試在跑的時候就會需要打開 500 次瀏覽器並且從頭 login 500 次。
- 不容易找到出問題的地方：同樣是因為一次就是測試一整個流程，所以只會知道結果是錯的，而不會知道錯誤出現在哪一個步驟。舉上面自動販賣機的例子，你只會知道自己拿到的不是珍珠奶茶，但到底是因為他在點單的時候錯誤了，還是在製作的時候錯誤了，甚至是在輸送的過程中出錯都有可能。
End-to-end Test 的覆蓋範圍
我們都希望自己的程式可以達到 100% 的測試覆蓋率，這樣就能確保自己的 code 萬無一失；但現實往往是殘酷的，通常不會有那麼多的時間可以讓我們寫這麼多測試。因此我們可以從眾多的功能中選出「重要的功能」以及「需要穩定的功能」這兩類來優先撰寫測試。
繼續沿用我們上面自動販賣機的例子，重要的功能就會是收到正確的錢才會開始做飲料。想想如果我們不小心修改了其中一個邏輯導致不管投多少錢進去，自動販賣機都會做一杯 30 塊錢的珍珠奶茶給你，那這樣老闆不就虧大了。所以這種功能就會需要 e2e test 來進行保護讓她不會發生錯誤。
那比較不需要進行保護的例子就可能是飲料的排序，其實對使用者來說，珍珠奶茶在左邊或是檸檬紅茶在左邊是可能只會稍微影響到他們的使用者體驗，但對於使用者以及廠商的利益而言，那個影響是很小的。所以這種在我們寫測試的時候就可以把優先順序放的比較後面一些。
結論
End-to-End test 可以算是我們 code 在給使用者之前的最後一道防線，也是最容易可以被上司看到的一種測試方式（可以直接讓他們按到瀏覽器在跑的狀況），所以他是一個蠻好開始測試的地方。之後會繼續利用框架的方式來介紹 end-to-end test，就讓我們繼續看下去～