在開源專案中,為了要確保程式碼的品質,並讓使用這個 SDK 的開發者能放心的使用,通常我們會寫一些自動化測試程式。
在這個專案中,筆者使用了 jest
搭配 ts-jest
來撰寫自動化測試程式。
jest 的文件內有教要如何讓 jest
搭配 ts-jest
來讓它支援 TypeScript 的設定方式,在此就不多加贅述。
假設有一個檔案 sum.ts
裡面的內容如下:
export function sum(a: number, b: number): number {
return a + b;
}
我們通常習慣會新增一個 sum.test.ts
檔案,撰寫相對應的測試程式:
import { sum } from './sum'
test('adds 1 + 2 to equal 3', () => {
expect(sum(1, 2)).toBe(3);
})
然後執行 jest
就可以看到測試結果囉。
為了要確保主要分支的每個 commit 都有被自動化測試保護,我們可以在 CI/CD 的流程中加入自動化測試的步驟,如果測試失敗,就不要繼續執行後續的步驟,這樣就可以避免有問題的程式碼被合併到主要分支中。
為了要讓 README.md 內有測試覆蓋率的 Badge,所以我們會需要透過 jest 來產生測試覆蓋率的報告:
$ jest --coverage
PASS src/buffer.test.ts
PASS src/Crypto1.test.ts (7.378 s)
------------|---------|----------|---------|---------|--------------------------------------------------------------------------------------------------------------------
File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
------------|---------|----------|---------|---------|--------------------------------------------------------------------------------------------------------------------
All files | 60.04 | 36.22 | 55.03 | 66.83 |
Crypto1.ts | 95.42 | 86.66 | 97.22 | 97.79 | 202-205,638
buffer.ts | 42.23 | 28.57 | 43.13 | 49.25 | 71-111,148-149,165-167,191-193,201-203,278-280,296-461,475-483,491,529-549,577-579,587-589,638-706,724-745,776-779
helper.ts | 27.27 | 16.66 | 27.27 | 33.33 | 15-40,45
------------|---------|----------|---------|---------|--------------------------------------------------------------------------------------------------------------------
至於上傳到 Coveralls 這個服務的部分,則是使用 GitHub Actions 來達成的,這部份的設定可以參考前幾天的文章內容。
雖然自動化測試程式很重要,但是時間不是無限的,我們不可能把所有的程式都寫上自動化測試,所以勢必會有一個寫測試的優先順序,然後再根據時間多寡來寫自動化測試。筆者之前曾經去聽過一些別人的經驗分享,以下是用來決定哪些程式需要優先寫測試的大致標準: