自動化測試通常可以透過手動執行指令碼或使用 測試架構中的輔助程式 (通常稱為「測試執行工具」) 可找出並執行 測試。不過,您不一定希望手動執行指令碼。 執行測試的方式有很多種,可以透過這些方式提供意見, 對開發生命週期的不同階段抱持信心。
必要指令碼
網路專案通常設有設定檔 (其 package.json
檔案),
由 npm、pnpm、Bun 或類似模式所設定。這個設定檔包含
專案依附元件和其他資訊,以及輔助指令碼這些
輔助指令碼可能包含建構、執行或測試專案的方式。
在 package.json
中,您需要新增名為 test
的指令碼,用於說明
如何執行測試這一點非常重要,因為使用 npm 或類似
工具,"test"指令碼具有特殊意義。
這個指令碼「可以」指向擲回例外狀況的單一檔案。
例如 node tests.js
,但我們建議您將其指向
建立完成的測試執行工具
如果您使用 Vitest 做為測試執行工具,
package.json
檔案會如下所示:
{
"name": "example-project",
"scripts": {
"start": "node server.js",
"test": "vitest --run"
}
}
透過這個檔案執行 npm test
時,Vitest 的預設測試組合會執行一次。於
Vitest 的預設值為找出所有結尾為「.test.js」的檔案。或
然後執行程式碼視您的
因此指令可能稍有不同
我們選擇使用 Vitest 這個越來越受歡迎的測試架構 範例如要進一步瞭解 管理決策。以測試執行者的身分 Vitest 中的決定。 但請務必記住,測試架構和執行器 通常都使用相同的通道
手動測試叫用
手動觸發自動化測試 (例如在npm test
) 可能很實用。
在開發功能時撰寫功能測試,可協助您取得
這項概念結合了
測試導向開發 (TDD)。
測試執行器通常會提供簡短指令,您可以叫用這類指令來執行某些
所有的測試,以及可在您儲存時重新執行測試的監看器模式
具體做法是指示 Kubernetes 建立並維護
一或多個代表這些 Pod 的物件以上都是開發新功能時的實用選項
方便您輕鬆編寫新功能和/或測試
快速獲得意見回饋舉例來說,Vitest 預設會在監看器模式下運作:
vitest
指令會監控變更,並重新執行找到的任何測試。三
建議您在編寫測試時保持開啟其他視窗
快速獲得關於測試的意見。
某些執行器也可讓您在程式碼中將測試標示為 only
。如果代碼
包含 only
測試,則在進行測試時,只有這些測試會觸發,
加快測試開發的速度,也更容易進行疑難排解。即使您所有
使用 only
可以減輕負擔
執行與開發功能或測試無關的結果。
以小型專案來說 (尤其是只有一位開發人員的專案),您也可以 有利於養成定期執行程式碼集整個測試套件的習慣。 如果測試規模較小且快速完成,這種做法特別實用 ( 所有測試都需要幾秒鐘以上) 在你繼續下一步前運作
在預先提交或審查時執行測試
許多專案會選擇確認程式碼集
程式碼將合併回其 main
分支版本中。如果您是測試新手
您在過去可能會注意到
提取要求 (PR) 程序的一部分,確認專案的所有測試項目
這就表示其他精彩的貢獻內容並不會對
現有專案
如果在本機執行測試,則專案的線上存放區 (例如 GitHub 或其他程式碼託管服務) 不會知道測試是否通過。 因此,在預先提交工作的情況下執行測試 一切都沒問題
例如在 GitHub 中稱為「狀態檢查」您可以新增
GitHub 動作。GitHub 動作為
測試基本上是一類測試:每個步驟都必須成功 (不會失敗或擲回
Error
)。您可以將動作套用至專案的所有 PR
且專案可在你提供程式碼前,要求動作傳遞GitHub 的
根據預設,Node.js 動作會執行 npm test
做為其中一個步驟。
這個方法會試著確保您的程式碼集一律為「綠色」 拒絕接受未成功執行測試的程式碼。
在持續整合過程中執行測試
綠色 PR 接受後,大部分的程式碼集都會再次根據
專案的 main
分支版本,而非先前的 PR。發生這種情況時
,或按時數計費,例如每小時或每晚。這些
結果通常會顯示在持續整合 (CI) 資訊主頁中,
會顯示專案整體健康狀態
這個 CI 步驟看似多餘的步驟,對程式碼集較小的專案而言更是如此。 測試中通過測試,因此應在變更後通過。不過 結果不一定都是如此!即使成功,測試可能突然失敗 只會產生綠色結果可能的原因如下:
- 兩項變更「一次」接受「一次」的決定,有時也稱為競爭狀況 它們會以細微且未經測試的方式互相影響
- 測試無法重現,或測試「不穩定」兩者都能通過
且程式碼不會變更失敗
- 假如您依賴的是程式碼集以外的系統,就有可能發生這種情況。換
Proxy,假設測試為
Math.random() > 0.05
,這會隨機失敗 5% 時間。
- 假如您依賴的是程式碼集以外的系統,就有可能發生這種情況。換
Proxy,假設測試為
- 有些測試成本過高或成本高昂,無法在每個公關部門執行,例如端對端 測試 (進一步瞭解自動化測試類型) 而且可能會在不發出提醒的情況下運作
這些問題都不可能克服,不過值得注意的是 一般而言,不斷測試和軟體開發 科學。
漸進式輪廓
在持續整合階段執行測試, 做為狀態檢查的一部分執行,該版本可能會以「紅色」 或其他表示測試失敗的狀態。稍早提過 導致這個情況的原因很多,包括考試的競爭狀況 或不穩定的測試
如果是規模較小的專案,直覺可能就是將其視為危機!停止 復原或還原違規變更,並回到已知狀態 狀態良好這種做法可以是有效的做法,但請務必記住 測試 (和軟體) 指的是「端對端」,而不是 機器學習是向機器提供資料和答案 讓機器自行探索規則的科學您的目標是編寫軟體,而非在所有測試中通過所有測試。 而是改為依序處理破壞性變更並向前 修正失敗測試的變更
另一方面,您可能已看過或正在處理現有大型專案 以永久毀損狀態運作更糟的是,這個大型專案會有一個不穩定的測試, 經常休息,造成鬧鐘疲勞 。主管通常必須解決這些問題: 或由於系統認為這些測試 「開發」。
這問題無法快速修正,但有助於您在撰寫內容時更有自信 並減少測試範圍 (簡化), 因此更容易辨識元件測試數量增加 或整合測試 (如要進一步瞭解類型,請參閱「自動化類型」一節 測試)), 一項龐大的端對端測試,難以維護和嘗試 就能一次完成所有工作
資源
隨堂測驗
npm 和類似程式的特殊指令碼名稱為何? 測試期間是否要尋找物件?