Visual Testing | MOPCON 2022 逐字稿
15 Oct 2022
「Visual Testing」MOPCON 2022 逐字稿。
歡迎搭配投影片與範例一同服用。
1
大家好，我是 Summer，今天想跟大家分享的是「Visual Testing」這個主題。
2
3
今天我想聊的主題是 visual testing，是測試的一環。
visual testing 是什麼呢？我們在測試 UI 的時候，遇到什麼樣的問題呢？
換個方式來問，我們在測試方面，已經有了很完善的 unit testing、integration testing 還有 end-to-end testing，這個 visual testing 在測試這一環上，扮演什麼角色呢？它能帶給我們什麼好處呢？
我們先來看遇到了什麼問題。
4
如果，老闆或是 PM 問問題，可以有一個排行榜，第一名一定是「為什麼一個功能，要做這麼久呢？」
那麼，第二名是什麼呢？就是「為什麼一個功能，要測這麼久呢？」
因為它有很多事情可以考慮、很多條路可以走。
5
所以，我們的第一個問題是「測試變因太多，手動測起來耗時費力」。
我們要測試的畫面受到很多因素影響，例如：解析度 (要測桌機、行動裝置)、瀏覽器 (要測 Chrome、Firefox、Safari) 甚至是各種操作流程的組合，而畫面的比對若依賴手動測試，這樣是非常耗時費力的。
6
我們小時候應該都玩過「威利在哪裡」的遊戲，從小在找威力這方面，我就是一個表現很平凡人的，可是現在天天都在找哪裡有 1px 的差異。
7
所以，第二個問題是「靠眼力」。
前面提到 UI 常常是靠手動測試，也就是靠人眼來比對畫面，但人眼比對畫面的能力是有限的，像是很多人只能看出 10px 的差異，這樣就很難做到 pixel perfect。
8
在做 PR review 時，我們常常不知道隔壁同事開發什麼好功能，我們很可能就是從 mockup 或程式碼來猜測到底做了什麼。
這時候若要從快照來回推 UI 到底改了什麼，根本就是做不到！為此，我們會針對自己做了什麼，在 PR 的說明附上截圖。
但是這個截圖在來回修改過程當中，很可能會忘了更新。 聽起來就是一場災難。
9
這就是我每天看 PR 的心情。
對我來說，花時間去了解別人在做什麼是很耗費精力的，自己的工作都做不完了，還要看別人的東西，真的很辛苦。
怎麼減輕我在 PR review 的負擔就變得很重要。
10
這個呢，就是第三個問題是「快照不夠直覺」。
我們在檢視 UI 是否有變更時，是檢視快照是否有更新，但這並不是真實使用者看到的畫面，而是 DOM 結構。
也就是說，我們從 DOM 結構的更新，來回推 UI 到底改了什麼。
我們自己在做 PR Review 時，會將 UI 手動截圖並做標記，告知 reviewer 到底改了什麼，也就是我們只看截圖 ，不看快照 😂
由於目前的快照方式不夠直覺、難以直接指出差異所在，因此希望能尋求更好的解決方案。
11
我們在開發階段，在提交程式碼時，會在本機跑一次 unit testing，跑完就會自動 push code。
但是往往一跑，就是跑到天花地老，泡完咖啡回來，才看到測試跑失敗了。
然後修改測試程式、再重新跑測試，來來回回就花了好多時間。
到底是什麼原因，讓我們測試跑這麼久呢？
12
這邊就會提到，第四個問題是「快照讓測試變得又大又慢」。我們遇到的狀況是…
- 快照會增加跑測試的時間，我們的專案曾大量使用快照，導致跑一次 unit testing 需要 20 - 30 分鐘 😂
- 再來，儲存快照需要大量空間，在我們的專案裡面，有的快照體積很大，大約是 3 MB、4 萬多行程式碼。
測試跑很久、儲存快照需要大量空間，又不能直接解決畫面比對的需求，這樣快照就顯得很沒用 😂
13
最後一個問題，就是我們的 end-to-end testing 是靠 selector 來做畫面比對的，但是 UI 的更動，往往會更新這些 selector，導致 end-to-end testing 跑失敗、pipeline 掛掉。
那麼，我們能不能盡量減緩這類的問題呢？或是說，讓畫面比對跟 end-to-end testing 脫鉤呢？
備註：感謝網友 Luke Chi 與網頁開發雜記的回饋，若另外用 data-* 而非 class 來做測試，是否能改善這個問題呢？在這裡整理一下討論串…
- 以 DX 來說，靠人手動新增修改 selector 是麻煩的，而且只要靠人做，都會有意外，希望能盡量避免。
- 以畫面比對來說，selector 不變，但畫面變了 (像是字串)，會無法檢測出來。
14
visual testing 可以解決以上的問題，讓我們 (1) 達到快又準的視覺比對，(2) 不用存太多東西，(3) 並且確保後續的測試能順利進行。
15
visual testing 是檢視 UI 視覺變更的一種測試，它對使用者看到的畫面做快照，然後做比對。
16
怎麼做 visual testing 呢？
分為兩種方式，第一種是針對元件，第二種是針對頁面。
17
我很推薦一開始在建立 visual testing 這個機制時，是以測試共用元件為起點。
這是因為我們在架構網站時，應該是像堆積木一樣，多數用共用元件堆積而成，那些像是重構、改 A 壞 B 的問題，都能經由測試共用元件，有效的檢測出來。
18
在針對元件方面，我自己是結合 Storybook、加上 visual testing 工具，像是 Chromatic 或 Percy，以及 CI/CD 工具，在這裡是 Github Action 來實現的。
- Storybook 包含專案當中所有共用元件的規格，因此，我們可以利用 Storybook 結合 visual testing 工具，像是 Chromatic 或 Percy 來對元件做快照。
- 再來，選用一種 visual testing service，像是 Chromatic 或 Percy，來幫我們對 Storybook 中的每一個 story 做快照。
- 最後，搭配 CI/CD 工具，幫我們自動完成這些事情。
19
作法是這樣的。
首先，安裝 Storybook、 Chromatic 或 Percy。
20
接著，撰寫 story 和測試程式，像是 play function。
21
再來，執行 Chromatic 或 Percy 的指令來跑測試和對元件做快照，我們可以選用在本機手動跑，或是用 CI/CD 自動跑。
22
最後，在 Chromatic 或 Percy 的服務平台上檢視快照。
23
想測試各種不同變因，要怎麼做呢？接下來我們以測試不同 viewport 為例。
24
如果我們想針對不同 viewport 做測試，要怎麼做呢？
在元件測試方面，我們可以在 Storybook 針對不同變因做設定，像是在 Storybook 的 config 或是個別 story 裡面設定參數，再帶入 Chromatic 或 Percy。
25
在這裡以 Chromatic 為例，如這張投影片的程式碼所示：
- 左邊的程式碼區塊，在 Storybook 的 config preview.js 做全域的設定，或是，像是
- 右邊的程式碼區塊，在個別 story 裡面設定了要檢測的 viewport 的 list。
接下來，就能執行 Chromatic 的指令，針對這個元件的不同 viewport 做快照了。
以上兩種方式都能達到讓 Chromatic 針對不同 viewport 做檢測的目的，這在同時有桌機和行動裝置的網頁很有用。
26
Percy 是怎麼做的呢？在 Percy 我們可以在它的設定檔來做設定，或是在執行 Percy 跑快照時的指令帶入即可。
如這張投影片的程式碼所示：
- 左邊的程式碼區塊，在 Percy 的設定檔做設定，或是，像是
- 右邊的程式碼區塊，單次測試的話，可以在執行 Percy 跑快照的指令
percySnapshot帶入參數。
這個方式是在頁面測試時會用到。
以上兩種方式都能讓 Percy 達到檢測針對不同 viewport 的目的。
27
當產生最新的快照之後，Chromatic 或 Percy 會幫我們與先前版本的快照做比對，並且標記不同的地方，接下來就能做 review。
28
前面提到的，是對元件的初始狀態做快照，若希望經過特定的操作流程後再做快照，要怎麼做呢？ 我們可以將這些互動，分為由 JavaScript 和 CSS 觸發兩種類型。
29
第一種是由 JavaScript 所觸發的狀況。
Mixtini 是一個推廣調酒與酒吧的線上服務網站，以它的搜尋功能為例，我們希望能模擬使用者在搜尋框輸入「愛爾蘭咖啡」後點擊搜尋按鈕，得到搜尋結果，再對這個搜尋結果做快照，讓我們來比對快照。
30
在這裡用 Storybook 結合 Chromatic 來對元件做快照。
如這張投影片的程式碼所示，在 story 裡面，實作 play function 來模擬使用者的操作行為。
也就是拿到搜尋框和搜尋按鈕的 DOM 元件，接著輸入「愛爾蘭咖啡」、點擊搜尋按鈕。
當完成 play function 內的所有工作後，Chromatic 便會對這個元件做快照，這樣就能達成對 JavaScript 所觸發的互動做快照的目的了。
31
第二種是由 CSS 所觸發的狀況。
以 Mixtini 的「聯絡我們」功能為例，希望對按鈕的 hover 狀態做快照。
32
第一種作法，是如左邊程式碼區塊，將 hover 狀態的樣式製作成 class，並且像右邊的程式碼區塊，在 story 加上這個 class 來做快照。
33
第二種作法，是利用 props 與 flag 的方式，來對不同狀態的 story 做快照。
- 左邊的程式碼區塊，在
<Button>元件中，利用 hover 這個屬性來決定元件的狀態。 - 右邊的程式碼區塊，在 story 中給定 hover 的值為 true，讓
<Button>呈現 hover 的狀態來做快照。
以上這兩種方式，便能達成對 CSS 所觸發的互動做快照的目的了。
34
在結合 CI/CD 工具上，我是用 GitHub action 來實現，我們可以整合 chromatic 的 GitHub action，自行撰寫 workflow 來達成自動測試元件和做快照的目的。
如這張投影片的程式碼所示，當提交 PR 時，會觸發 Chromatic publish Storybook、做元件測試和做快照。
35
除了對元件做快照外，我們也可以結合 end-to-end testing 工具，像是 Cypress，來對頁面做快照。
36
在針對頁面方面，我自己是結合 Cypress、加上 visual testing 工具 Percy，以及 CI/CD 工具，在這裡是 Github action 來實現的。
37
以 Mixtini 的首頁為例。
38
在這裡，我們結合 Cypress 與 Percy，來對頁面做快照。
如這張投影片的程式碼所示，在瀏覽 Mixtini 的首頁後，percySnapshot 這個指令會幫我們對 Mixtini 的首頁做快照，並且把快照上傳到 Percy 的服務平台上，稍後片刻便可以在 Percy 看到快照的比對結果。
39
在 Percy 上可以看到許多資訊，主要功能像是
- 在右上角，可以根據瀏覽器和解析度，檢視快照的狀況。
- 在右邊區塊， Percy 會幫我們與先前版本的快照做比對，並且標記不同的地方。
若確定本次變更是我們所預期的，就可以按下左上角的 approve 按鈕，那麼本次的快照就會成為之後比對的基準。
40
在結合 CI/CD 工具上，同樣我也是用 GitHub action 來實現，我們可以整合 Percy 的 percy-cli 工具，並且，自行撰寫 workflow 來達成自動測試特定頁面和做快照的目的。
如這張投影片的程式碼所示，我們可以設定每週一早上 12 點定期對特定頁面做測試與做快照。
41
總結以上的工作流程：
- 第 1 步：跑測試，可以選用 Storybook 結合 Chromatic 或 Percy 來做元件測試，或是用 E2E testing 工具像是 Cypress 來做頁面測試。
- 第 2 步：針對元件或是頁面做快照。
- 第 3 步：比對快照，找出不同點。
- 第 4 步：根據快照，可以選擇更新程式碼或是更新快照的比較基準。在這個步驟，可能會回到第 1 步跑測試，來回多次。
- 第 5 步：確認無誤後，即可 merge 程式碼和上線。
42
我們聊了怎麼做 visual testing 後，接下來要來看，快照的比對原理是什麼？
43
一開始，我們從 main 的 commit x 切出 branch A，x 所產生的快照是 main 與 A 的比較基準，稱為 baseline。
接著 main 與 A 都有新的 commit 加入，而每一個 commit 都會產生自己的快照，若我們同意這些快照需要更新，它們就變成新的 baseline。
如這張投影片所示，main 在 x 後依序加入 y 和 z；而 A 在 x 之後，依序加入 p 和 q。因此，main 的 baseline 是 z 所產生的快照，而 A 的 baseline 是 q 所產生的快照。
44
A 在 commit q 時提交 PR，想要 merge 回到 main 時，這時候就會比對 z 和 q 所產生的快照。
若此時同意 q 的快照作為新的 baseline，在 A merge 回到 main 後，q 所產生的快照就會成為 main 的 baseline。
45
若此時 reject q 所產生的快照呢？
那就要選擇修改程式碼，像是加上 commit r，並且 z 依然是 baseline，不需要我們再次接受 r 所產生的快照為 baseline。
為了簡化說明，我就沒有標記由 merge 所產生的 commit 等狀況。
由以上可知，快照的比對，主要是跟著 git commit 走的。
46
若想將 visual testing 導入工作流程，選哪個工具好呢？我們來比較 Chromatic、Percy 和常用的 jest-image-snapshot。
47
第一，Chromatic 與 Percy 的快照是真實使用者看到的畫面，而 jest-image-snapshot 則是 DOM 結構。
這裡順帶一提， 免費版本的 Percy 即可測試 Chrome、Firefox 和 Edge，而免費版本的 Chromatic 只能測試 Chrome。
48
第二，在比對快照的方式上，Chromatic 與 Percy 可以在自身平台上做到，而 jest-image-snapshot 要靠版控工具。
49
第三，如果想要比對程式碼，Chromatic 可以在自身平台上做到，而 Percy 和 jest-image-snapshot 要靠版控工具。
50
第四，如果想要依照 PR 或 branch 來檢視快照，Chromatic 可以在自身平台上很輕易的做到，Percy 在自身平台上可以做到但是沒有這麼好用，jest-image-snapshot 要靠版控工具。
相較之下， Chromatic 的 UI 功能比較完整、比較好用的，大家有興趣的話可以玩玩看。
51
第五，在元件測試上，當我們整合了 Chromatic 或 Percy 的 GitHub action 後，便可將 visual testing 的結果作為 PR review 的 critiria，jest-image-snapshot 要靠版控工具做 code review。
52
如這張投影片所示，PR 的 conversation 區塊，會提示有多少快照需要被 review，這時候可以點擊「Details」連結到 Chromatic 或 Percy 的服務平台上做 review，選擇 approve 來接受本次的快照成為新的 baseline 或 deny 來維持原本的 baseline，review 完成後就會變成綠勾勾，讓開發者能夠 merge 程式碼。
53
第六，在元件測試上，Chromatic 與 Percy 都可以結合 Storybook 來實現，jest-image-snapshot 則是要靠自己撰寫該元件的測試程式來做比對。
54
最後，在頁面的測試上，Percy 和 jest-image-snapshot 可以結合 E2E testing 工具來實現，而 Chromatic 只有元件測試。
55
Chromatic 和 Percy 都是很棒的 visual testing 工具，我們來比較這兩個工具主要差異。
Chromatic 的優點是：
- 第一，Chromatic 的 UI 簡單好用，像是前面提到，想要依照 PR 或 branch 來檢視快照，Chromatic 可以在自身平台上很輕易的做到。
- 第二，專注在元件測試，有很完整的功能，像是指定不檢測哪些元件、visual noice 的 threshold 的設定，都能很方便的設定。如果只是想導入元件測試，我是很推薦 Chromatic 的。
Percy 的優點是：
- 第一，包山包海，在元件測試和頁面測試兩者皆有，如果想要一套工具打天下，Percy 絕對是首選。
- 第二，免費版本的 Percy 即可測試 Chrome、Firefox、Edge，相較之下，免費版本的 Chromatic 就只能測試 Chrome。
- 第三，他們的接洽窗口很棒，相較 Chromatic，Percy 的業務和技術團隊在跟我們討論一些事情上，相對積極，如果是需要跟廠商密切談合作，Percy 在這一點上很加分。
我是覺得，挑一個自己用起來順手、適合團隊的工具就可以了。
在後面，我也會談到為什麼沒有選用 cypress-image-snapshot (請參考投影片#97)。
56
在實作 visual testing 機制上，我的作法是
首先，利用 Storybook + Chromatic 來做元件測試，在 PR review 時檢視共用元件是否如預期呈現。 再來，利用 Cypress + Percy 來做頁面測試，定期在 production 上檢視特定頁面的狀況。 最後，砍掉 jest-image-snapshot。
57
對我來說，剛剛那樣「用 Storybook + Chromaitc 做元件的快照」以及「用 Cypress + Percy 做頁面的快照」是滿分的組合，但是在工作上和 side project 上，我要怎麼取捨呢？
所謂「理想是豐滿的，現實是骨感的」大概就是這個意思。
58
前面提到，我在建立 visual testing 的機制時，是利用 Storybook + Chromatic 來做元件測試，在 PR review 時檢視共用元件是否如預期呈現。
選用 Chromatic 是因為它的 UI 好用，如果我希望團隊會喜歡，降低上手的難度會是重要考量，這是為什麼我選用 Chromatic 做元件測試的原因。
59
不過由於公司的政策，像是要跟廠商談合作流程，這個過程很冗長，不太可能為了用兩種工具而跑兩次流程，為了降低導入的成本，最後選了同時能測試元件和網頁的 Percy。
不過以上都是我的考量，大家可以評估自身情況做選擇。
60
看起來 visual testing 是個好東西，那麼實際執行的成效如何呢？ 有沒有解決我們的煩惱呢？ 像是先前提到的
- 第一，測試變因多，手動測起來耗時費力。
- 第二，靠肉眼比對，難以做到 pixel perfect。
- 再來，快照不夠直覺，難以指出差異所在。
- 還有，測試大又慢，產生與儲存快照耗費大量時間空間。
- 最後，E2E Testing 包山包海。
等等這些問題。
61
首先，在面對各種變因，只要設定好，並結合 CI/CD 工具，就能自動完成測試，解決先前提到的測試變因多，手動測起來耗時費力的問題。
這就能減輕 QA 的工作負擔，QA 表示開心。
62
再來，由於是用工具比對，因此絕對比用肉眼來得準確，解決了人眼比對畫面的問題。
63
而且，由於 visual testing 所產生的快照是真實使用者看到的畫面，而不是 DOM 結構，因此，改什麼，一目了然，解決了「快照不夠直覺」的問題，這在 PR review 時很有幫助。
對現在來說比較有價值的倒不是原本預期的視覺設計上的比對，而是 wording 的比對，尤其在 i18n 的處理上能讓我們更容易辨識文字的差異，對於英文或其他非母語的語言，是很有用的。
64
我們來看到底省多少時間和空間。
我們在自己的產品裡面，比較用 Percy 和原本的 jest-image-snapshot 來產生快照…
- 在本機跑測試，Percy 幫我們減少了 98% 的時間，我們產生快照的時間，從 20 - 30 分鐘減少到 30 秒，主要是減少產生快照的時間，就能提升開發速度。
- 在儲存快照上，Percy 幫我們存在它的服務上，節省了我們自己存快照的空間。
這個實際測試的詳細數據，之後會再跟大家分享。
65
visual testing 的元件測試，是綁在 unit testing 或 integration testing 上，與 end-to-end testing 相比，成本低、又不會花太長時間，能常常跑，能降低我們跑測試的成本和時間。
66
在這裡有個例子，我們對同一個頁面做測試。
- 左邊程式碼區塊，用原先的方式，檢查某個元件存不存在、文字是什麼來做比對。
- 右邊的程式碼區塊，就是對該頁面做快照。
相較之下，右邊的能確認的細節就比較多，而且程式碼的量比較少。
67
所以，比起測試某個 selector 存不存在，比對元件或頁面的快照能比對更多細節，因此能提高測試的覆蓋率。
68
更重要的是，我們就讓 visual testing 做它最擅長的工作吧！就是畫面比對。
69
前面提到，我們的 end-to-end testing 是靠 selector 來做畫面比對的，但是 UI 的更動，往往會更新這些 selector，導致 end-to-end testing 跑失敗、pipeline 掛掉。
如果我們使用 visual testing 來做畫面比對，畫面比對的工作就能與 end-to-end testing 脫鉤，確保 end-to-end testing 順利進行，進而提升 pipeline 的穩定度。
70
最後…
由於 visual testing 能幫我們自動做畫面比對，並給我們人看得懂的快照，在 review UI 或程式碼時能一目了然知道改了什麼，讓我們從忽略快照，到有效使用快照。
還有，不再需要寫測試程式比對畫面，要撰寫和維護的測試程式碼的量和時間都變少了。 因此開發體驗變好了。
71
接下來我們來看一些疑難雜症，也就是我踩過的雷，還有一些在導入過程中解決的問題。
72
對於老系統來說，如果一開始沒有寫測試，之後也是很難寫測試的。
visual testing 提供了一個儘量不用寫測試的測試方法，也就是靠畫面比對來做初步偵錯，這對不難寫測試的系統也同樣適用。
在我們自己的專案裡面，有些地方很難寫測試，我們就把這個頁面整頁放到 Storybook 裡面，用元件測試的方式做快照，然後只比對快照，只要快照是對的，基本上就認定功能是對的。
73
如果我們要測試的內容是不固定的，像是廣告，或是跟使用者的狀態、選擇有關，要怎麼處理呢？
74
第一種解法，是事先塞入假資料，讓內容維持一致。
75
在這裡，我們再次以 Mixtini 的搜尋功能為例，我們事先從 Storybook 塞入搜尋結果的假資料，這樣當模擬使用者在搜尋「愛爾蘭咖啡」後，不論資料庫是否更新，拿到的都是事先給定的假資料，快照就能維持一致。
76
第二種解法，是忽略這個會變動的區塊。
77
例如，Chromatic 讓我們在 HTML 上加上 class name chromatic-ignore 就可以忽略這個元件，不做比對。
78
如果有些頁面要等待動畫執行完畢才做快照，要怎麼處理呢？
79
在這裡以 Mixtini 的首頁為例，Mixtini 的首頁在載入時會有 fade in 的特效，但是我們還沒等他做完就快照了，導致快照只有部份的內容，要怎麼處理呢？
解決方法是針對這個 story 設定 delay 時間，待動畫執行完畢再做快照。
- 左邊的快照是我們沒有設定 delay 時間，導致還沒做完動畫就被快照。
- 右邊的快照是在 story 設定 delay 為 300 ms，等待動畫完成後，再做快照。
80
不過，如果是效能問題，最好的方法，當然是提升載入或渲染效能。
81
如果對前端效能的議題有興趣，歡迎參考
這兩本書 🚀
(老莫在現場，跟大家打招呼)
82
要求 pixel perfect 是專業的，不過有時候，我們不需要這麼敏銳的比對，要怎麼處裡呢？
我們可以設定 threshold 來略過 visual noise 😂 不過到底要調多少，是需要跟團隊一同討論和測試的。
83
如這張投影片，將文字右移 1px，對於大多數使用者來說，差異並不顯著。 以 Chromatic 為例，設定其參數 diffThreshold 來決定這樣的差異是否為 visual noise。
- 左圖的 diffThreshold 為 0，也就是任何差異都會被標記出來。
- 右圖的 diffThreshold 改為 0.05，即可忽略將文字右移 1px 狀況。 Chromatic 可設定 0 ~ 1，預設值是 0.063，而 Percy 則是提供三個斷點「Strict」、「Recommended」和「Relaxed」，也就是五個區段可做選擇，不過這是要付費的。
另外，在 A/B Test 方面，若希望不同版本的內容差異或相似度管控在某個範圍內，也可以用 visual noise 的 threshold 來做檢測。
84
在跑測試的時候，我們常會遇到一個問題，就是「在我的電腦跑沒事，可是在別人的電腦跑卻有事」的狀況。
85
如這張投影片所示，左邊的快照是我在 local 跑的，右邊的快照是在 CI/CD 的環境上跑的。
由於環境的不同，導致字體載入速度不同，讓瀏覽器在字體載入策略上有不同的展現，而導致快照產生差異，在這裡是以 Safari 為例。
在這個狀況下，由於大家各自的開發環境各異，因此我們的解法是，快照被 accept 為 baseline，是以 CI/CD 環境所產生的快照為主，也就是提交 PR 或是 commit 到 GitHub 時觸發的測試所產生的快照為 accept 的 baseline，就不會是自己的本機跑測試後上傳的快照當成 baseline。
因此，關於環境的問題，我們沒有確切的解法，只能靠工作流程解決。
86
最後要聊的問題是，我們只要有新的 commit，就算不是 UI 的更新，也會被要求 review 快照。
原來，Chromatic 和 Percy 是參考 git history 來比對的，沒有 git history 就無法得知這個 commit 的 parent 和 child，也就無法得知在指定的 branch 上的快照更新狀況。
由於預設只會存取一個 commit，因此要設定 fetch-depth: 0 是來存取所有分支的歷史紀錄和標籤。
這裡可以注意到，快照的比對會參考 git history，所以 rebase 或 squash merge 或 rebase merge 都不會影響快照的比對結果。
87
來總結誰適合做 visual testing、事前需要準備什麼、有什麼好處。
如果你正在評估要不要做 visual testing，也許可以參考這次的分享。
88
基本上，只要有畫面的系統，都適用。
與其聊什麼狀況適用做 visual testing，不如聊什麼狀況不適用。
不適用的狀況像是…
- 第一種是，沒有版本控管，如果程式碼沒有做版本控管，我們就沒有比較基礎和管理流程。
- 第二種是，畫面太頻繁更新，如果產品還沒有要保持「穩定」，那就不需要做這樣的測試。
89
visual testing 需要準備什麼呢？
需要準備 Storybook 或 end-to-end testing 工具，搭配 visual testing 的服務，這樣就能讓我們來做元件或是頁面的測試。
90
visual testing 能帶給我們什麼好處？
- 第一，省時省力省空間。
- 第二，精確比對。
- 第三，提升覆蓋率，同時也能減少寫測試的量和維護測試程式碼的時間。
- 第四，visual testing 幫我們率先排除了一些問題，讓後續測試能順利進行、順便提升 pipeline 穩定度。
- 最後是，提升開發的爽度。
91
我做了一個簡單的 repo 來 demo 如何使用 Chromatic、Percy 和 Cypress 來做 visual testing。
這裡面會有
- 怎麼用 Storybook 和 Chromatic 跑元件測試。
- 怎麼用 Percy 和 Cypress 跑頁面測試。
- 怎麼結合 GitHub action 的 workflow 自動跑測試。
也就是，本次分享的重要程式碼都可以在裡面找到。
有興趣的人可以玩玩看。
92
歡迎大家一同加入 visual testing 的行列！
93
特別感謝我的合作團隊 Mixtini、Sean Chou、Shawn Lin、Yvonne Huang、Alvin Wu、Gordon Lin 和我的公司趨勢科技。
94
本次分享會有逐字稿。
以上是我的分享，感謝大家！
95
為了避免 QnA 冷場，我有準備幾個自問自答跟大家分享。
96
第 1 個問題是「導入 Visual Testing 遇到最大的困難是什麼？」
是「流程跑很久」。
因為要用到 Chromatic 和 Percy 這類型的服務，要請廠商跟公司簽訂保密協議 (NDA)，這一塊需要對方與自己公司的法務和管架構流程的人來看，要跑很久，相較起來技術上的問題都不是難題。
97
第 2 個問題是「考慮用 Cypress 的 snapshot 嗎？」
是「不考慮」。
由於我們的終極目標是拔掉快照，或是讓快照不要放在自己專案裡面，而且不想自己開發檢視快照的系統，因此選擇用現成的服務。
不過，如果公司很難導入外部工具，這的確是一個解法。由於大多數的 E2E 工具都有這樣的對畫面快照的功能，是可以經由一些調整來做 workaround 的。像是我們可以把 Storybook deploy 到 AWS 後，再用 cypress 等去打網址做元件測試，這樣對於無法或不想多用其他工具來說是一個解法，但是比對快照、存快照就要靠自己處理，必須取捨。
98
第 3 個問題是「設計師能參與這樣的工作流程嗎？適合和設計師合作嗎？能用在工作上嗎？」。
在我們的工作流程裡面，在上線前會做所謂的 UI review、visual review 和 wording review，通常都是在 staging 階段的時候讓設計師進來 review，但這樣真的太慢了，希望可以提前到修改程式碼時就可以進來 review，以加快開發速度。
Chromatic 和 Percy 提供我們一個解決方案，讓非工程師的角色，像是設計師，能在我們提交變更時，就進來檢視是不是他們想要的。
但這在工作流程的整合的推行上是有一定門檻的，像是工具的整合、PR review 需要更多的時間可能會導致延遲進 code，所以我並沒有想要推行在與設計師溝通這方面上，不過如果是自己的 side project，我會很推薦這樣的工作流程。
99
第 4 個問題是「最推薦 visual testing 的點？」
答案是「PR review 時，一目瞭然改了什麼」。 如同前面提到的，對我來說，花時間了解別人改什麼是很耗費精力的，自己的工作都做不完了，還要看別人的東西，真的很辛苦。
怎麼減輕我在 PR review 的負擔就變得很重要。
我們都會很認真寫 PR 的描述，visual testing 提供了一個更直覺、更有效的溝通方式，這是我最喜歡它的地方。
100
還有更多問題嗎？歡迎大家交流討論。
QnA
Q1: 免費版的 Percy 支援 Safari 嗎？
免費版的 Percy 支援 Chrome、Firefox、Edge、Safari，其中 Safari 是我漏講了。可參考投影片 #85 左上角有 Safari 的選項可點選。
