目前作法 1. 挑選變化型最多（aka 人工測起來最麻煩）的 component 做自動化測試 2. 以撰寫規格書大綱的原則來替 test cases 分類與下標 3. 套用 Clean Code 第三章的原則自訂 functions 來處理同一參數的不同變化型 4. 用設定檔和自訂的 functions 開啟 / 關閉測試行程中的 screenshot 動作
之前上了 Testing JavaScript with Kent C. Dodds 課程後，開始替公司產品前端撰寫 end to end 測試，使用課程中介紹的 Cypress 這套工具。目前為止做了兩個 component 的自動化測試，這兩個 component 的性質分別是導覽精靈以及對話視窗。使用感想如下：
Cypress 的優點
安裝簡單
用 npm i 或 yarn add 無痛安裝，這應該是勝過 Selenium 的最大賣點吧 XD語法親民
大部分語法都來自既有的熱門 library，所以蠻友善的，測試是 Mocha 跟 Chai，selector 是 jQuery。我第一次寫測試，之前其實也沒用過 Mocha 跟 Chai，但還是可以無痛上手。圖形介面直覺
Cypress Test Runner 對初學者來說也蠻直覺的，打開後會把測試資料夾裡面所有的 .js 檔案列出來，按下檔名後會召喚出一個加料版的 Chrome，左側邊欄列出該檔案裡面的 test cases，右側主畫面則是一個 iframe 包著指定的 baseUrl，照著左側邊欄的 test cases 跑。每個 test case 都可以展開看詳細步驟，每個步驟還可以定格看他的 before and after 比對，在 debug 的時候蠻方便的。號稱輔助工具方便
課程中提到 Cypress Test Runner 因為呼叫的瀏覽器是 Chrome，所以可以用 Chrome dev tools 的各種功能。但實際用起來，因為下面會提到的效能的關係，這個功能對我來說實在用不到 wCypress 的缺點
效能
課程提到，開發過程中，可以拿 Cypress 幫你把 component 的 state 按到想要的地方，原本這是最吸引我的一點，但實際使用後覺得不可行，因為 Cypress 一開，我的 CPU 就超過 100%、風扇狂轉、反應變慢，headless 模式還好，GUI 模式則非常嚴重，根本不可能應付開發過程中頻繁更新的需求... 不曉得這跟 Electron 有沒有關係 :Q （我的筆電是 Macbook Pro Retina 2015 版）跨瀏覽器
目前只支援 Chrome 家族，不過 Firefox 跟 IE 已經在進行中，感覺指日可待（？）官方有把進度更新在 這個 GitHub issue。覺得實用的地方
記錄技術規格
由於產品正在從 prototype 變身到 production，很多規格會隨著早期使用者的意見調整來調整去，對規格的描述則散落在各不同時期的 issues 中，加上我的導覽精靈跟對話視窗這兩個 component 有非常多不同的變化型，一不小心自己都會搞混。這種時候，直接把規格集中寫在測試檔裡面，從文件整理的角度來看是蠻方便的。製作文件
產品 deliver 時要交付的使用手冊，要用到很多 screenshots，很多時候還要裁切到特定的 dom element。以往工人截圖的時候每次 UI 更新就要重做一遍，現在直接把截圖動作寫在 cypress 測試裡，他會在指定的步驟用指定的方式裁切、然後自動用 test case title 幫每張截圖命名，真的很方便 lol結語
之前在研究網頁前端測試的時候，逛到一篇 Cypress 跟 Selenium 的比較文，裡面有句話覺得蠻好笑但蠻貼切的：
Cypress vs. Selenium, is this the end of an era? I truly believe it is the end of Developers don’t test era.
由於 Cypress 可以無痛上手，而 end to end 測試本身又可以立即節省人工，對我這種初次寫測試的菜鳥來說，是非常經濟實惠的選擇，一來不需要麻煩老鳥來幫忙安裝環境，二來花費的時間成本也不會高到讓 PM 難以接受。如果你的處境跟我類似，可以考慮試試看 😃
沒有留言:
張貼留言