首先感謝隊長 Ian 的邀請，也感謝隊友們的鼓勵，終於要結束 30 天的挑戰了
其實大概寫到一半就沒料了，後面變成開始自己亂看亂摸索，反而是給自己強制學習的機會

這系列遇到的雷點與解法不見得都是我親身遇到，也有很多是前輩們的經驗與努力

寫 E2E 之旅

剛開始去面試實習的時候，還記得面試官問我有沒有興趣寫測試
當時的我完全不知道這是什麼，簡單 google 一下，感覺應該就是寫寫腳本類的東西

browser.click('<element>')

枯燥乏味

大約過了一兩個月，當初的面試官問我會不會覺得很無聊、枯燥乏味
當時的我大概還停留在只會

browser.click('<element>')
       .assert('<element2>')

我當時覺得這比較像是可以偷閒的工作，反正無腦寫就好

寫 leetcode

過了一段時間後，開始正式執行 E2E 的測試，我才知道原來每種瀏覽器都會測
當時經歷了痛苦的修改期，每個已經寫過的都要拿出來改
隨後開始學習客製化指令，把比較複雜的步驟變成一個指令，這樣就可以不用同時改很多檔案
還記得我的第一個就是 checkColorSafe() 當時面試官在 MR 留了「你真帥」XD

在我經歷寫了幾個月 E2E 之後，我覺得它像 leetcode，針對題目敘述解題
並且會用一些客製化指令完成一些任務

browser.checkColorSafe(
    '<element>',
    'background-color',
    'rgba(61, 186, 144, 1)',
);

寫框架

但又經歷半年之後，我認為它像寫一個大型框架，怎麼寫的好、寫的彈性更是重要

善用 Page object / command 已經不夠了，如何在測試網站每次有比較大的更新時，能快速反應變成了我的目標
希望讓整個專案可以適應不同機器規模、可以當有期間限定的 UI 出現時，能夠繞過、可以透過 CI/CD 讓框架變得很彈性等。

module.exports = {
    isSpercialUi: process.env.isSpercialUi || false
}

dashboard.login()

module.exports = {
  command: async function(type) {
      if (this.globals.isSpercialUi)
          // do something
  }
}

可視化

除了彈性外，能夠輸出讓執行者能快速理解的功能也很重要
之前的篇幅有提到可以利用一些套件、google sheet 或是上 browserstack 查看
不過如果善用 Nightwatch 的 message 其實也很重要

Nightwatch 在使用 assert/verify 時，其實都有這個 optional 的 api 叫 message

寫一個好懂 message 搭配原生的勾勾或叉叉，應該還是比其他方法更為快速且精準

總結

這系列文應該提供了

• 與物件互動會遇到的麻煩問題
• 與跨瀏覽器時會遇到的奇妙問題
• 測試框架更彈性的寫法與挑戰
• BrowserStack 或其他可視化套件與方法

希望這個系列可以給未來剛學習 E2E 的人，可以不用頻頻到各個網站找解法
可以直接從這裡參考～