本文已發布超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
聚焦 SIG Testing
歡迎來到SIG spotlight部落格系列的又一期，我們在此重點介紹 Kubernetes 專案中各個特殊興趣小組 (SIG) 所做的出色工作。在本期中，我們將焦點轉向 SIG Testing，這是一個對 Kubernetes 的有效測試和自動化專案繁瑣工作感興趣的小組。SIG Testing 專注於建立和運行工具及基礎架構，以便社群更輕鬆地編寫和運行測試，並貢獻、分析測試結果並根據測試結果採取行動。
為了深入了解 SIG Testing，Sandipan Panda 與 Google 的資深軟體工程師兼 SIG Testing 主席 Michelle Shepardson，以及 Intel 的軟體工程師兼架構師和 SIG Testing 技術主管 Patrick Ohly 進行了交談。
認識貢獻者
Sandipan： 您可以向我們介紹一下您自己、您的角色，以及您是如何參與 Kubernetes 專案和 SIG Testing 的嗎？
Michelle： 嗨！我是 Michelle，Google 的資深軟體工程師。我最初參與 Kubernetes 是透過為 SIG Testing 開發工具，例如 TestGrid 的外部實例。我是 TestGrid 和 Prow 隨時待命團隊的一員，現在是 SIG 的主席。
Patrick： 您好！我在 Intel 的一個團隊中擔任軟體工程師和架構師，該團隊專注於開源雲原生專案。當我開始深入研究 Kubernetes 以開發儲存驅動程式時，我的第一個問題是「如何在叢集中測試它以及如何記錄資訊？」這種興趣引導我提出了各種增強提案，直到我（重新）編寫了足夠的程式碼，並且還接任了 SIG Testing 技術主管（負責 E2E 框架）和結構化日誌記錄 WG 負責人的官方角色。
測試實務和工具
Sandipan： 測試是一個存在多種方法和工具的領域；你們是如何採用現有的實務的？
Patrick： 我無法談論早期，因為那時我還沒加入 😆，但是回顧一些提交歷史，很明顯開發人員只是使用了可用的東西並開始使用它。對於 E2E 測試，那是 Ginkgo+Gomega。一些臨時解決方案是必要的，例如在測試運行後清理和分類測試。最終，這導致了 Ginkgo v2 和 修訂後的 E2E 測試最佳實務。關於單元測試，意見非常分歧：一些維護者更喜歡僅使用 Go 標準函式庫和手寫檢查。其他人則使用像 stretchr/testify 這樣的輔助套件。這種多樣性是可以接受的，因為單元測試是獨立的 - 貢獻者在處理許多不同領域時只需保持彈性。整合測試介於兩者之間。它基於 Go 單元測試，但需要複雜的輔助套件來啟動 apiserver 和其他元件，然後運行更像 E2E 測試的測試。
SIG Testing 擁有的子專案
Sandipan： SIG Testing 非常多元。您可以簡要概述 SIG Testing 擁有的各種子專案嗎？
Michelle： 廣義上來說，我們有與測試框架和基礎架構相關的子專案，儘管它們肯定有重疊之處。因此，對於前者，有 e2e-framework（外部使用）、test/e2e/framework（用於 Kubernetes 本身）和用於端對端測試的 kubetest2，以及 boskos（用於 e2e 測試的資源租賃）、KIND（Kubernetes-in-Docker，用於本地測試和開發）和 KIND 的雲端供應商。對於後者，有 Prow（基於 K8s 的 CI/CD 和 chatops），以及用於分類、分析、覆蓋率、Prow/TestGrid 配置生成以及 test-infra repo 中更多其他工具和實用程式。
如果您願意了解更多資訊並參與任何 SIG Testing 子專案，請查看 SIG Testing README。
主要挑戰和成就
Sandipan： 您面臨的一些主要挑戰是什麼？
Michelle： Kubernetes 在各個方面都是一個龐大的專案，從貢獻者到程式碼再到使用者等等。測試和基礎架構必須滿足這種規模，跟上 Kubernetes 下每個 repo 的每次變更，同時盡可能促進專案的開發、改進和發布，當然，我們並不是唯一參與其中的 SIG。我認為另一個挑戰是子專案的人員配置。SIG Testing 有許多已經存在多年的子專案，但是它們的許多原始維護者已經轉向其他領域，或者不再有時間維護它們。我們需要在這些子專案中培養長期的專業知識和所有者。
Patrick： 正如 Michelle 所說，龐大的規模可能是一個挑戰。不僅是基礎架構，我們的流程也必須隨著貢獻者的數量而擴展。記錄最佳實務是好的，但還不夠好：我們有很多新的貢獻者，這很好，但是讓審閱者解釋最佳實務並不能擴展 - 假設審閱者甚至知道這些實務！現有程式碼無法立即更新也沒有幫助，因為它太多了，尤其是對於 E2E 測試。在接受現有程式碼未通過相同的 linter 檢查的同時，對新的或修改後的程式碼應用更嚴格的 linting 的倡議有所幫助。
Sandipan： 有沒有您感到自豪並想重點介紹的 SIG 成就？
Patrick： 我有偏見，因為我一直在推動這件事，但我認為 E2E 框架和 linting 現在比以前好得多。我們可能很快就能夠在啟用競爭條件檢測的情況下運行整合測試，這很重要，因為我們目前僅對單元測試具有該功能，而單元測試往往不那麼複雜。
Sandipan： 測試始終很重要，但是就 Kubernetes 發布流程而言，您的工作有什麼特別之處嗎？
Patrick： 測試不穩定… 如果我們有太多這種情況，開發速度就會下降，因為 PR 在沒有乾淨的測試運行的情況下無法合併，而這種情況變得不太可能。開發人員也會失去對測試的信任，並且只是「重新測試」直到他們獲得乾淨的運行，而沒有檢查失敗是否確實與他們當前變更中的回歸有關。
人員和範圍
Sandipan： 關於這個 SIG，您最喜歡的事情是什麼？
Michelle： 當然是人 🙂。除此之外，我喜歡 SIG Testing 的廣泛範圍。我覺得即使是很小的變更也可能對其他貢獻者產生很大的影響，即使我的興趣隨著時間的推移而改變，我也永遠不會沒有專案可做。
Patrick： 我可以從事使我和我的同事開發人員的生活變得更好的事情，例如我們每天在其他地方開發新功能時必須使用的工具。
Sandipan： 有沒有什麼有趣/酷/今天學到的軼事可以告訴我們？
Patrick： 我在五年前開始從事 E2E 框架增強功能，然後有一段時間不太活躍。當我回來並想測試一些新的增強功能時，我詢問了如何為新程式碼編寫單元測試，並且被指向一些看起來有點熟悉的現有測試，就好像我以前見過它們一樣。我查看了提交歷史，發現那些測試竟然是我寫的！我讓您來決定這是否說明我的長期記憶力衰退，或者只是正常現象…… 無論如何，各位，請記住編寫良好的提交訊息和註解；有人會在某個時候需要它們 - 甚至可能是您自己！
展望未來
Sandipan： 您的 SIG 需要在哪些領域和/或子專案中獲得幫助？
Michelle： 目前有些子專案沒有人員配置，並且可以使用願意了解更多資訊的人員。boskos 和 kubetest2 對我來說尤其突出，因為兩者對於測試都很重要，但缺乏專門的所有者。
Sandipan： SIG Testing 的新貢獻者可以帶來哪些有用的技能？如果人們來自與程式設計沒有直接關聯的背景，他們可以做些什麼來幫助這個 SIG？
Michelle： 我認為使用者同理心、編寫清晰的回饋和識別模式非常有用。使用測試框架或工具的人可以透過清晰的範例概述痛點，或者可以識別專案中更廣泛的問題並提取數據來為其解決方案提供資訊。
Sandipan： SIG Testing 的下一步是什麼？
Patrick： 更嚴格的 linting 將很快成為新程式碼的強制要求。如果有人願意承擔這項工作，則可以現代化幾個 E2E 框架子套件。我也看到一個統一我們用於 E2E 和整合測試的一些輔助程式碼的機會，但這需要更多的思考和討論。
Michelle： 我期待為我們的一些工具和基礎架構做出一些可用性改進，並支持更多的長期貢獻和貢獻者成長為 SIG 內的長期角色。如果您有興趣，請與我們聯繫！
展望未來，SIG Testing 有令人興奮的計畫。您可以透過他們的 Slack 頻道與 SIG Testing 的人員聯繫，或參加他們每週二定期舉行的 雙週會議。如果您有興趣讓社群更輕鬆地運行測試並貢獻測試結果，以確保 Kubernetes 在各種叢集配置和雲端供應商中保持穩定，請立即加入 SIG Testing 社群！