我們與測試的距離 - 黃冠霖

tags: MOPCON 2019

講師介紹

• 黃冠霖(神Q超人)
• 主要出現在討論區與線下聚會

為什麼我們需要學寫測試

• 為什麼需要測試
  • Q: 甚麼時候會改變
  • A: 不知道，所以我們需要做測試
  • 我們總是在人工測試

• 人工測試的缺點：

  • 花費時間長

  • 測試樣本不同，造成測試結果可能不同

  • 無法精準確認問題在哪裡發生

    • 只能看 log 慢慢猜
    • 受限環境，無法隨時測試

  • 測試完後沒有任何數據報告產生

    老闆："你有測試過嗎？"

    厭倦了一次又一次的測試嗎？也許人工測試是必須的，但在那之前，我們能否有效減少錯誤？

擁抱單元測試吧！
為專案裡的每一單元撰寫測試
建立安全的防護網

什麼是單元？

也許你有聽過最小單位的function就是單元
但這樣說更好…
程式裡每個單一行為，才是單元

單元測試的優點

• 只測試單一行為， 能夠精準發現問題在哪
• 測試樣本相同，程式邏輯不便，結果就不變
• 想測試時隨時都可以進行測試
• 花費時間短
  • 讓確認程式是否正確的難度降低(非開發人員也能確認程式狀況)
• 測試後能產生測試報告，作為測試指標

單元測試的缺點

• 沒有測試個別單元之間的溝通
  • 可能個別是好的，但接起來就爆了
• 有可能單元測試是通過的，但在程式執行時也有可能發生完全不符合該情境的狀況發生。

單元測試不是萬能藥

如何寫好單元測試

• 讓人對測試的結果有信心
  • 當你看見原本通過的測試不通過時，不會這麼說：「咦？是不是測試案例哪裡有問題？」而是：「天啊！我剛剛到底做了什麼？」
  • 沒信心就變成在維護兩份code

這部分可以去思考當時在撰寫程式的時候，因為架構沒有調整好，導致程式與程式之間的耦合度太高。

• 可讀性的測試必須擁有___以及___

Live demo 中用到的技巧

• 為測試案例取一個好的命名與好的內容
  • 好的命名的需求:
    • ex:add_UseParam1and1_Return2
    • 對誰做
    • 做了什麼
    • 期望會有甚麼結果(要把他回傳的結果有明確的寫好)
  • 好的內容(3A原則)
    • Arrange:安排
    • Act:執行
    • Assert:斷言
      • 解釋:是否有符合我們的期望
• 可以用測試報告確認程式的健康度
• 在程式碼(非測試程式)中加入測試特徵
  • ex:在前端的element加測試特徵

    優：不用擔心前端改位置而使測試讀取失敗
    缺：程式可讀性不佳，只因測試文件所需而加上沒什麼需要的名字

Example:

//add.js
const add = (number1, number2) => {
    if (typeof number1 !== 'number' || typeof number2 !== 'number')
        throw new Error();
        
    return number1 + number2
};

export default add;

//add.test.js

import add from 'add.js';

// good nameing: 'add_UseParam1and1_Return2' 
// bad nameing: 'add_useTwoParam_ReturnSum' <-無法得知是要測（1+1）還是（3+10）等

test('add_UseParam1and1_Return2', () => {
    // Arrange (安排)
    const expected = 2
    // Act (執行)
    const actul = add(1, 1)
    // Assert (斷言)
    expect(actul).toBe(expected)
});

• 單元測試的困難
  • 有多種框架，每種框架用法都不同
  • 框架更新後，用法也可能因此改變

    無法一種通用

jest.mock

幫網頁前端測試

• 加入測試特徵

  • 不用class, 因為他根本不需要css,會降低程式可讀性

• 插件
  jest
  test-libary/react