提交後測試政策

提交後測試驗證 Beam 在實際環境中是否正常運作。這些測試還可以捕捉在設計和實施階段難以預測的錯誤。

即使提交後測試是在程式碼合併到儲存庫後執行，但測試可靠地通過仍然非常重要。Jenkins 會針對 master 分支的 HEAD 執行提交後測試。如果提交後測試失敗，則表示 HEAD 建置有問題。此外，提交後測試執行耗時，且通常難以分類測試失敗。

政策

為了確保 Beam 的提交後測試可靠且健全，Beam 社群遵循以下提交後測試政策

• 先回滾
• 失敗的測試是嚴重的錯誤
• 不穩定的測試是嚴重的錯誤
• 不穩定的測試必須修復或移除
• 提交後失敗的修復應包含相應的新提交前測試

提交後測試失敗情境

當提交後測試失敗時，請按照您情況提供的步驟操作。

我發現測試失敗

1. 建立一個 GitHub 議題 並將其指派給自己。

• 元件：測試，以及任何其他相關元件
• 標籤：precommit
• 在描述中參考此頁面。

1. 對失敗進行高階分類。
2. 將議題指派給相關人員.

我被指派了一個測試失敗的議題

1. 回滾有問題的變更.
2. 如果您確定回滾需要超過 8 小時，請在回滾或建立修復程式時，暫時停用測試。

注意：回滾始終是第一優先的行動方案。如果修復程式很簡單，請在回滾時開啟一個包含建議修復程式的 pull request。

我的變更因測試失敗而被回滾

回滾後，有時間進行更深入的調查。首先查看 GitHub 議題，以了解回滾的背景資訊。以下情境都很常見

• 您的變更包含錯誤。
• 您的變更暴露了現有的錯誤。
• 您的變更暴露了不良測試（不穩定、過度指定等）。

這些都是回滾的有效原因。保持清晰的信號是最高優先事項。

高階步驟相同

1. 建立修復程式並重新執行提交後測試。
2. 實作新的提交前測試，以便在未來程式碼合併到儲存庫之前捕捉類似的失敗。
3. 開啟一個新的 PR，其中包含您的修復程式和新的提交前測試。

如果錯誤不在您的程式碼中，以下是「建立修復程式」的方法

1. 如果現有錯誤尚不存在，請為其提交問題單。請記住，不穩定的測試是嚴重的錯誤。其他不良測試也類似：它們可能因為與正在測試的內容無關的任意原因而失敗，這使得我們的信號不可靠。
2. 標記有問題的測試以跳過，並附上 GitHub 議題的連結。

實用連結

• 撰寫測試的最佳實務

參考資料

1. 保持提交後測試綠色郵件列表提案執行緒。