Vite Unit Test,Vite 測試價值

測試價值

  1. 製作一個簡易的測試工具
  2. 寫測試案例
  3. 寫受測程式碼的實作

簡易的測試工具

1
expect(受測物).toBe(預期狀態)
  • 回傳 true 表示測試成功 （即為最終狀態與預期狀態相同）
  • 回傳 false 表示測試失敗 （即為最終狀態與預期狀態不同），然後加上 error 提示預期狀態應該要是什麼，最終狀態目前是什麼。
宣告函式 expect，參數則是預計輸入受測物（input）;再來工具本身呼叫時需回傳了一個叫做 toBe 的驗證方法，該驗證方法的參數為預期目標（expected）;接著設計該驗證的方法，使其能夠回應測試的結果 
1
2
3
4
5
6
7
8
9
10
const expect = (input) => {
    // 接著設計該驗證的方法，使其能夠回應測試的結果
    const toBe = (expected) => input === expected
    return {
        toBe
    }
}
//現在我們透過網頁瀏覽器的 devtool console 控制台，就可以透過該測試工具做簡易的測試案例了
expect(1 === 1).toBe(true)
expect(2 !== 1).toBe(true)
但我們希望他能夠在測試案例失敗的時候回應一下當下預期與結果的狀況，後續我們才能針對紀錄的結果做修正。因此我們再修改一下測試方法： 
1
2
3
4
5
6
7
8
9
10
const expect = (input) => {
    const handleOnError = (result, expected) => {
        console.error(`測試失敗：預期應該為 ${expected}，結果現在為 ${result}`)
        return false
    }
    const toBe = (expected) => input === expected ? true : handleOnError(input, expected)
    return {
        toBe
    }
}
再執行一個故意寫錯的測試案例： 
1
expect(2 === 1).toBe(true)

實際一點的例子說明;有個登入的表單元件
測試案例在 Vitest 工具中主要便是透過 describe 與 it（或 test） 來撰寫

錯誤的相關資訊：

  • FAIL：發生斷言錯誤檔案路徑 + 情境描述 + 案例描述（視當下錯誤所屬的情境與案例）
  • AssertionError：發生斷言錯誤的原因，與發生錯誤的段落
  • Expected：預期結果
  • Received：實際結果

綜合結果：

  • Test Files：總共測試了幾隻測試檔案，並顯示成功、失敗與跳過的數量
  • Tests：總共測了幾個測試案例，並顯示成功、失敗與跳過的數量
  • Start：測試開始時間
  • Duration：測試過程總共耗費時間
請看單元測試結果 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
describe('登入元件', () => {
    // Happy Path
    it('輸入正確帳號密碼，應登入到ＯＯ頁面', () => {
        // ...
    })
    // Sad Path
    it('只輸入帳號，應該顯示請輸入密碼', () => {
        // ...
    })
    it('只輸入密碼，應該顯示請輸入帳號', () => {
        // ...
    })
    it('輸入錯誤帳號密碼，應該顯示登入資訊錯誤', () => {
        // ...
    })
})
允許巢狀的方式來建構測試 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
describe('父層情境', () => {
  describe('基於父層情境的情境一', () => {
    it('測試案例', () => {
        // ...
    })
  })
  describe('基於父層情境的情境二', () => {
    it('測試案例', () => {
        // ...
    })
    it('出現提示寄件者姓名與電話將直接註冊成會員', () => {
        // ...
    })
  })
})

describe & it 輔助 API

  • .only：測試情境、測試案例皆可使用
  • .skip：測試情境、測試案例皆可使用
  • .todo：測試情境、測試案例皆可使用
  • .fails：測試案例才能使用

only

若在測試情境用了此指令，則在同個測試檔案中只會執行帶有 .only 的測試情境，而其餘測試情境底下所有的測試案例將會被跳過（skipped）：
1
2
3
describe.only('測試情境 1', () => { /* */ })
describe('測試情境 2', () => { /* */ }) // skipped
describe('測試情境 3', () => { /* */ }) // skipped
若在測試案例中使用，則除了帶有 .only 之外的測試案例都將會被跳過：
1
2
3
4
5
6
7
8
9
10
11
describe('測試情境 1', () => {
  it.only('測試案例', () => { /* */ })
  it('測試案例', () => { /* */ }) // skipped
})

describe('測試情境 2', () => {
  it.only('測試案例', () => { /* */ })
  it('測試案例', () => { /* */ }) // skipped
})

describe('測試情境 3', () => { /* */ }) // skipped

skip

測試情境或測試案例被標注時，將自動跳過該範疇內的測試案例：
1
2
3
4
5
6
7
8
9
describe.skip('測試情境 1', () => {
  it('測試案例', () => { /* */ }) skipped
  it('測試案例', () => { /* */ }) // skipped
})

describe('測試情境 2', () => {
  it('測試案例', () => { /* */ })
  it.skip('測試案例', () => { /* */ }) // skipped
})

todo

測試情境或測試案例被標注時，同樣將自動跳過該範疇內的測試案例，但 todo 含義比較接近待加入測試的區塊，並且將來若產出報告時也會特別整理出還有哪些地方需要補上測試。

fails

最後一個介紹的是測試案例才能使用的輔助 API，還記得列測試案例時的 sad path 嗎？當測試案例應該要失敗的時候就可以透過 fails 顯性標註他們：
1
2
3
4
it.fails(`'1' + '1' should not to be '11'`, () => {
  const add = (x, y) => Number(x) + Number(y)
  expect(add('1', '1')).toBe('11')
})
當然你也可以單純藉由斷言中的 .not 達到同樣的效果： 
1
2
3
4
it(`'1' + '1' should not to be '11'`, () => {
  const add = (x, y) => Number(x) + Number(y)
  expect(add('1', '1')).not.toBe('11')
})
準備（Setup）與清理（Teardown）
  • beforeEach：在每個測試案例執行前呼叫一次
  • beforeAll：在所有測試案例執行前呼叫一次
  • afterEach：在每個測試案例執行後呼叫一次
  • afterAll：在所有測試案例執行後呼叫一次
1
2
3
4
beforeEach(() => {
    // 針對測試案例重新初始化
    initTestEnv()
})
Setup & Teardown API 的範疇
Setup & Teardown API 「所有」的定義是根據當下的範疇（context）來決定，除了測試檔案本身之外，使用 describe 來定義測試情境也會形成一個 context，因此假如測試情境有巢狀的情況如下： 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
const history = []
describe('父層情境', () => {
  beforeAll(() => {
    history.push('beforeAll - 父層情境')
  })
  beforeEach(() => {
    history.push('beforeEach - 父層情境')
  })
  afterAll(() => {
    history.push('afterAll - 父層情境')
  })
  afterEach(() => {
    history.push('afterEach - 父層情境')
  })
  describe('子層情境 A', () => {
    beforeAll(() => {
      history.push('beforeAll - 子層情境 A')
    })
    beforeEach(() => {
      history.push('beforeEach - 子層情境 A')
    })
    afterAll(() => {
      history.push('afterAll - 子層情境 A')
    })
    afterEach(() => {
      history.push('afterEach - 子層情境 A')
    })
    it('案例 1', () => {
      history.push('子層情境 A 案例 1')
    })
    it('案例 2', () => {
      history.push('子層情境 A 案例 2')
    })
  })
  describe('子層情境 B', () => {
    beforeAll(() => {
      history.push('beforeAll - 子層情境 B')
    })
    beforeEach(() => {
      history.push('beforeEach - 子層情境 B')
    })
    afterAll(() => {
      history.push('afterAll - 子層情境 B')
    })
    afterEach(() => {
      history.push('afterEach - 子層情境 B')
    })
    it('案例 1', () => {
      history.push('子層情境 B 案例 1')
    })
    it('案例 2', () => {
      history.push('子層情境 B 案例 2')
    })
  })
})

此時將透過 console.log(history) 查看並歸納整理就能得到以下結果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
--- 進入測試程式碼本身的 Context
--- 進入父層情境的 Context
beforeAll - 父層情境
--- 進入子層情境 A 的 Context
beforeAll - 子層情境 A
beforeEach - 父層情境
beforeEach - 子層情境 A
子層情境 A 案例 1 // 執行 情境 A 案例 1 的時間點
afterEach - 子層情境 A
afterEach - 父層情境
beforeEach - 父層情境
beforeEach - 子層情境 A
子層情境 A 案例 2 // 執行 情境 A 案例 2 的時間點
afterEach - 子層情境 A
afterEach - 父層情境
afterAll - 子層情境 A
--- 離開子層情境 A 的 Context

--- 進入子層情境 B 的 Context
beforeAll - 子層情境 B
beforeEach - 父層情境
beforeEach - 子層情境 B
子層情境 B 案例 1 // 執行 情境 B 案例 1 的時間點
afterEach - 子層情境 B
afterEach - 父層情境
beforeEach - 父層情境
beforeEach - 子層情境 B
子層情境 B 案例 2 // 執行 情境 B 案例 2 的時間點
afterEach - 子層情境 B
afterEach - 父層情境
afterAll - 子層情境 B
--- 離開子層情境 B 的 Context
afterAll - 父層情境
--- 離開父層情境的 Context
--- 離開測試程式碼本身的 Context
避免誤區：在 expect 後做清掃處理
除了上面的用法，有時候你可能會認為既然要清掃，那我何不在斷言後處理就好呢： 
1
2
3
4
5
6
7
describe('', () => {
    it('', () => {
        expect().toBe()
        // 在這裡做清除
        resetTestingEnv()
    })
})
這麼做當你在測試案例都是通過的情況下都沒有問題，但是一但某個測試案例發生了錯誤，由於測試案例就會在斷言時拋出 AssertionError 後停止，因此很有可能因為一個測試案例壞了導致接下來所有測試都受到影響： 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
describe('', () => {
    it('', () => {
        expect().toBe() // AssertionError，這個測試案例就停在這了
        resetTestingEnv() 
    })
    it('', () => {
        // 在沒有經過 `resetTestingEnv()` 下進行測試
    })
    it('', () => {
        // 在沒有經過 `resetTestingEnv()` 下進行測試
    })
    it('', () => {
        // 在沒有經過 `resetTestingEnv()` 下進行測試
    })
    it('', () => {
        // 在沒有經過 `resetTestingEnv()` 下進行測試
    })
})
因此較佳的作法還是使用 Setup & Teardown API 來處理會比較好： 
1
2
3
4
5
6
7
8
9
10
11
12
13
describe('', () => {
    beforeEach('', () => {
        setupTestingEnv()
    })
    afterEach('', () => {
        resetTestingEnv() 
    })
    it('', () => {})
    it('', () => {})
    it('', () => {})
    it('', () => {})
    it('', () => {})
})
避免過度使用 Setup & Teardown API
抽象光譜（The Spectrum of Abstraction）
Setup & Teardown：beforeAll, beforeEach, AfterAll & AfterEach 】斷言（Assertion）上篇：斷言語法與 Matchers 斷言（Assertion）下篇： 替身、快照（Snapshot）與拋出錯誤

第一個測驗：測試情境案例、Setup & Teardown 與 Matchers
測試工具： Vue Test Utils 與元件測試
元件測試：容器（Wrapper）
元件測試：容器方法（Wrapper methods）－選擇器與陷阱
元件測試：容器方法（Wrapper methods）－取得目標資訊
元件測試：容器方法（Wrapper methods）－模擬事件
元件測試：模擬 Vue APIs（data, props）
元件測試：模擬 Vue APIs（slots, custom directives）
第二個測驗：容器（Wrapper）與容器方法（Wrapper methods）