# 今晚，就來點前端測試，隨意聊篇

嗨嗨，晚安～

對初心者而言，直接進入一團扣有些時候很容易就喪失了焦點，因為要注意的細節太多了，我就是那個很容易喪失焦點的初心者（嘆氣）

所以在進入前端手把手測試教學前，讓我們來一系列 QA，why and how，先對測試有一個大輪廓

> Q1- 為什麼我們需要寫測試 ? 為什麼前端需要寫測試 ？

問題的根本就在於畫面與資料的交互作用

你的畫面狀態可能會很複雜。想像這是一個協作的專案，在很災難的情況下，大家的變數命名甚至狀態宣告都可能重複，更甚者有可能你自己為了方便就宣告了好多個狀態，結果一個地方忘了維護導致其他地方受到影響，就這樣逼死自己，恭喜您升天成就達成。

我就做過這件事情，在深夜一點多看著自己的代碼想著怎麼辦？

前端的測試就是要測試狀態的交互關聯，與後端的測試不太一樣，沒有什麼複雜的商業邏輯．所以絕大多數情況下，你要測的會是使用者的操作在畫面上的效果跟你預期的是否一致，也就是測試行為。

依照測試的範圍從小到大分別為：單元測試 / 整合測試 / end-to-end 測試

> Q2- 整合測試與單元測試又差在哪裡？什麼時候要用單元，什麼時候又要用整合？

讓我們用一個小故事說明兩者的差異。

小明為了實現自給自足的生活，決定什麼都自己來，從早餐到晚餐，餐餐都自己煮，不光是自己煮食物，連食材也要自己種自己養，想吃牛就養牛，想吃菜就種菜～

自己煮的總是最安心、最健康，就連食材都一手包辦不含任何化學農藥、瘦肉精精精，怎麼可能吃出問題呢？

但人生就是有這麼多個 BUT，某天小明上吐下瀉，難以置信的小明決定去驗證到底是哪一個環節出錯了？

食材壞掉是因為他不新鮮？他被隔壁的工業廢水污染到？還是說是因為我組合出來的食物是相生相剋？就像養樂多與香腸，最遙遠的距離，不是朋友的朋友

單元測試就是對程式碼的最小可測試範圍進行測試，以上面的故事來說我們可以這麼寫，去驗證測試我們的蔬菜是否壞掉

 test('蔬菜應該壞掉', () => {
  // 1. 被隔壁的廢水污染
  // 2. 放太久臭掉了
  // 3. 被嫉妒我的人偷灑農藥
  // 4. 蟲害
  // 5. 太陽太大了
 })

整合測試，整合多方資源進行測試，確保模組與模組之間的互動行為正確無誤，也讓不同模組在各自開發維護的過程中不會因為功能調整而遭到破壞。以上面的故事而言，蔬菜沒壞、香腸沒壞、養樂多沒壞，但全部組合就變成一盤有毒料理

私自認為，前端畫面大多數的情況下，都是要驗證測試狀態之間的交互作用，基本上會跨元件的，所以寫前端測試時，也會以整合測試居多～

> Q3- 前端測試要如何寫？他的架構會是什麼？

這邊不會提到任何 Code，純閒聊

欲學框架，必忘框架～先讓我們忘記那些煩人的框架或套件，如果沒有他們，你會怎麼寫測試？

要測試行為要先有畫面，所以會先想辦法將我要測試的畫面進行 render，render 完後要能夠選到畫面上的元素，選到元素我才能知道元素的狀態甚至樣式跟我想的是否一樣，如果一樣符合我的測試要求就給他過，不一樣就讓他死。

誒誒，但有些時候我要測的內容會變動，導致我每次要測的內容都受到干擾，既然如此何不就將這些會影響我測試會變動的項目 mock 起來，讓他固定住，讓他的替身代替他進來我的測試

就這樣，你已經學完了，超快吧ＸＤＤＤ

1. 要測行為就要先有畫面：所以將你要測試的檔案 import 進來後，透過 react-testing library 讓他 render 出來
2. render 完後要能夠選到畫面上的元素：所以 react-testing library 提供了相對應的 api 讓我們可以選到元素
3. 有些時候選取元素，可能會涉及到你的動作，所以我們要想辦法去觸發動作， react-testing library 也提供了相對應的 api，又因為你的動作會造成元素的狀態改變，比方說滑鼠移動出現 popOver，樣式會因為你選擇的切版軟體不同而不同。所以練習寫測試一定要打開你的 dev-tool 觀察樣式的改變。
4. 說到動態改變，就要想到非同步拉～如果是非同步我測試的 api 要使用哪一個？
5. 再來，測試的精華，要測之前要先準備哪些材料，哪些材料是會變動影響我測試的？準備好這些相關材料後我要怎麼去 mock 他們，讓他們的值固定，這樣一來才不會影響我要測試的項目麻？
6. 最後，選到的元素是否跟我想的一樣，所以我要有一個 test runner 幫我執行這個判斷，這邊我們是用 jest-dom

總之，你大概會需要兩個東西，一個幫你做 dom 節點的操作，一個幫你做 test runner

我覺得測試難的點在要看懂它噴的錯誤，錯誤有二類
1. 測試寫錯
* 語法錯誤
* 選取元素錯誤，通常是非同步的情境少考慮了
* 切版實作與你的測試不穩合
* mock 出問題
* 非同步的 issue ...
2. 原本的代碼就是錯的
* 比較難找，要順著你的代碼慢慢找，我都慢慢 console

好處是，有了測試重構比較不會擔心，尤其是那邊的扣不是你寫的，但不論我們怎麼實作最後我們的扣都要通過測試的考驗～

另外，測試不好寫的一點在於，作為一個初學者，你的學習一定是從簡單的測到複雜的，但很不幸的通常專案都是大的，要 mock 跟留意的地方超多，沒有前人的腳步要從零到一是件很艱辛的任務！所以先試著練習一個從小到大的部落格或什麼的，先測試再切版做功能，會對測試有更多的感覺～

總之，有了基礎架構，就讓我們一步步進入測試的世界ˊˇˋ