測試執行位置

自動化測試通常可以透過手動執行指令碼或使用 測試架構中的輔助程式 (通常稱為「測試執行工具」) 可找出並執行 測試。不過，您不一定希望手動執行指令碼。 執行測試的方式有很多種，可以透過這些方式提供意見， 對開發生命週期的不同階段抱持信心。

必要指令碼

網路專案通常設有設定檔 (其 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% 時間。
• 有些測試成本過高或成本高昂，無法在每個公關部門執行，例如端對端 測試 (進一步瞭解自動化測試類型) 而且可能會在不發出提醒的情況下運作

這些問題都不可能克服，不過值得注意的是 一般而言，不斷測試和軟體開發 科學。

漸進式輪廓

在持續整合階段執行測試， 做為狀態檢查的一部分執行，該版本可能會以「紅色」 或其他表示測試失敗的狀態。稍早提過 導致這個情況的原因很多，包括考試的競爭狀況 或不穩定的測試

如果是規模較小的專案，直覺可能就是將其視為危機！停止 復原或還原違規變更，並回到已知狀態 狀態良好這種做法可以是有效的做法，但請務必記住 測試 (和軟體) 指的是「端對端」，而不是 機器學習是向機器提供資料和答案 讓機器自行探索規則的科學您的目標是編寫軟體，而非在所有測試中通過所有測試。 而是改為依序處理破壞性變更並向前 修正失敗測試的變更

另一方面，您可能已看過或正在處理現有大型專案 以永久毀損狀態運作更糟的是，這個大型專案會有一個不穩定的測試， 經常休息，造成鬧鐘疲勞 。主管通常必須解決這些問題： 或由於系統認為這些測試 「開發」。

這問題無法快速修正，但有助於您在撰寫內容時更有自信 並減少測試範圍 (簡化)， 因此更容易辨識元件測試數量增加 或整合測試 (如要進一步瞭解類型，請參閱「自動化類型」一節 測試))， 一項龐大的端對端測試，難以維護和嘗試 就能一次完成所有工作

資源

• 擁有夜間版本的優點

隨堂測驗