[緣起] 前端 E2E 測試的困境

與其它自動化測試不一樣，前端的 E2E 測試一直是個老大難問題，難點主要在於 如何描述測試。

自動化測試的核心是檢查特定輸入能不能獲得符合預期的結果。對於單元測試和 API 測試來講，「特定輸入」就是函數或者接口的參數，結果也是當前語言的數據類型或者通用的好比 JSON，兩者一方面好描述，另外一方面好驗證。寫起來就沒什麼難度。

好比

sum(a, b) {
 return a + b;
}

要驗證輸入 1 和 2，返回 3，則能夠寫成：

const assert = require('assert');
describe('sum', function() {
  it('should equal', function() {
    assert.equal(sum(1, 2), 3);
  });
});

這裏輸入輸出都很容易描述，因此自動化測試就沒什麼難度。

可是 UI 的 E2E 測試並不是如此。UI 是作給用戶看的，因此，一個 UI 的 E2E 測試應該寫成這種形式（這裏拿一個相似於活動行的應用來舉例子）：

1. 打開應用首頁
2. 顯示活動列表
3. 點擊列表中的任一項
4. 進入活動詳情頁
5. 點擊報名按鈕
6. 登記我的信息
7. 點擊付費按鈕
8. 完成付費
9. 看到報名成功的信息

這個過程中用戶的操做，很難和程序當中的抽象產物，好比按鈕、列表等產生關聯。操做的結果，「進入下一頁」，也很難進行進一步的校驗。

因此在以前的生產實踐中，你們喜歡用選擇器來進行 E2E 測試，表明產品有 Cypress 和 Nightwatch。我以爲，這裏一方面有 jQuery 帶來的使用習慣延續和思惟定勢；另外一方面，藉助 XPath，找到特定元件，進行交互操做和校驗元素幾乎是你們惟一的選擇。

使用 CSS 選擇器的方案並不完美，好比：

1. 選擇器自己，和 UI 視圖可能並無強關聯，寫出來的測試可讀性不強，一段時間以後回頭去看，極可能會看不懂。
2. HTML 的 DOM 結構並不穩固，隨着功能增減版本迭代常常發生變化，這個時候咱們就要跟着修改測試用例。
3. DOM 結構不能反應視圖的真實狀態，極可能會出現雖然測試經過，但實際上在用戶眼裏仍然是錯誤的表現。

那麼，說了這麼多不容易、其它方案的不完美，個人解決方案又是怎麼樣的呢？

這裏請允許我賣一下關子，下次再介紹由我廠 OpenResty Inc. 打造的前端自動化工具 Navlang。

---

你們好，我是 Meathill，目前在 OpenResty Inc. 負責前端開發工做。今年我會利用業餘時間，介紹我廠在前端方面的工做，包括各類垂直領域，好比自動化、基於 DevTool Protocol 開發、WebExtension 開發、Vue、CodeMirror、組件化等等，內容包括進展、經驗、心得、踩坑、產品等。

歡迎你們關注本專欄，也歡迎你們光臨個人博客：山維空間。若是你有任何疑問問題均可以在 SF 和個人博客上向我發問，我必定儘可能答覆。