身為前端工程師的我，兩年前曾聽前公司主管在介紹 “錄影自動化測試” - selenium IDE (分享內容類似這篇部落格)，但當時學習曲線等級還沒到那邊，一直沒實際用到過。

前幾個月，在交付需求前後，被一件事驚醒發現自動化測試的必要性。這件事就是：我必須手動 end-to-end 測試同一個表單 42 遍（42 種 test case），而且是 本機、測試機、正式機各要測 42 遍，而且企劃下個月仍會調整需求，所以又要重複手動測試，這時候我總算是尋求 selenium IDE 的懷抱，隔一個月有成效後，剛好有個機會和同事分享，在同事的合作下，開始了針對新需求的 end-to-end 測試。

selenium IDE 的好處是非工程的 QA 人員也可以自己操作。不過後面在工程主管建議下，嘗試了分工： QA 出 test case 表，前端依據 test case 寫自動化測試程式 （Nightwatch.js），前端在初步交付（QA 驗收測試機）前測試完，並註明簡易指令讓 QA 也能開終端機自己操作。這麼一來，QA 甚至能將多餘的測試時間挪移到使用者體驗的部分。

為什麼選 Nightwatch.js ? 一方面是基於 selenium 、官方文件 齊全且 stackoverflow 問題超過千筆 了，另一方面是部門另一位同事，在前一年有推動過 Nightwatch.js，雖然當時因為種種因素先作罷，目前部門已經有研究的基底了。接下來就是個人學習成長要加強的部分，我在教學文章、文件、需求同時交疊實作學習之下，一項一項寫 test case，交付時因為自動化測試加強了機械化重複的手動測試這塊，自己就有信心達到品質要求，實際上品質也有提升。等到有實作經驗後，我開始去看教學文，這時看了比較有感覺。

接下來的幾篇會以以下章節不限順序寫下去：

• 測試一個產品的策略、測試一個產品的 test case、ＢＤＤ
• test suite 生命週期
• babel
• 檔案架構
• 表單驗證
• 表單送出 XMLHttpRequest
• url 導頁
• 畫面顯示
• Cookie 驗證
• 迴圈頁面
• 切換頁籤
• 等待頁面整理完成
• Debug: perform
• nightwatch-html-reporter
• 同時執行多隻測試
• edit form input 測試 可用 isVisible
• 好用指令例如 browser.rtUrl('www').maxmizeWindow().saveScreenShot('./test.png')
• custom commands
• custom assertions

參考文章：
https://cythilya.github.io/2018/03/26/nightwatch101