owned this note   changed 4 years ago  
Linked with GitHub

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

歡迎來到 MOPCON 2019 共筆

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

共筆入口：https://hackmd.io/@mopcon/2019
手機版請點選上方 按鈕展開議程列表。

會場 wifi-SSID: mopcon-2019
會場 wifi-PASSWD: mopcon-2019

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

Select a repo