前端測試原來沒這麼單純

為什麼要寫測試?

坦白說在台灣時從來沒寫過測試，反正開發完丟給 QA 部門就對了。

前後端開發完 -> QA 部門測試 -> pass
^                 |
|                 |  
|           fail  |
-------------------

但畢竟 QA 也是人，還是可能遇到一些問題例如

• 改了 A 功能，壞了 B 功能 (QA 只會測新功能)
• 上個版本明明沒問題，這個版本卻出現問題
• QA 不爽為什麼每發布一次版本就要求重覆測試浪費時間
• 覺得離職同事寫得很爛但很難 refactor ，因為不知道哪邊可能會壞
• 很害怕改共用 component 因為怕原本的被改壞只好複製一個出來改

來美國後我們公司沒 QA 部門，卻完全不會遇到以上問題，為什麼呢?

因為每一個工程師都要求要寫 “測試”，而且規定程式碼 testing 要 coverage 到 80% 以上你的 PR 才會被 approve。

前後端開發完 -> run 各種 test -> pass
^                    |
|                    |  
|               fail |
----------------------

聽起來很美好，但問題來了。原來前端測試這麼多樣化，unit testing、integration testing、e2e、snapshop… 天阿前端這領域要學的也太多了吧!! 為了要混口飯吃我只好硬著頭皮從零開始學了

Unit Testing

test one piece of code(usually one function)
基本觀念是對 function 進行測試，由開發人員寫的，自己的 Code 自己測試

// add.js
const add = (a, b) => a + b;
// add.test.js
test('2 + 3 預期等於 5', () => {   
  expect( add(2, 3) ).toBe(5); 
})

前端比較常聽到是 mocha.js、jest.js。unit testing 非常容易實現(不需要複雜的設定)，但其實撰寫 testing 邏輯跟開發產品不太一樣，所以初學者(像我)，也是需要切換另一種角度去學習。自己寫了一系列 Unit Test (Jest + Enzyme) 文章也可以做參考~

Unit testing 之 Jest.js 還有他的好夥伴 enzyme (目前為止有五篇)