本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
聚焦 SIG Testing
歡迎來到新一期的 SIG 聚焦 部落格系列，我們將重點介紹 Kubernetes 專案中各個特別興趣小組（SIG）所做的令人難以置信的工作。在本期中，我們將注意力轉向 SIG Testing，這是一個致力於有效測試 Kubernetes 並自動化專案繁瑣工作的團隊。SIG Testing 專注於建立和執行工具與基礎設施，使社群更容易編寫和執行測試，以及貢獻、分析和處理測試結果。
為了深入瞭解 SIG Testing，Sandipan Panda 採訪了 Michelle Shepardson，她是 Google 的高階軟體工程師和 SIG Testing 的主席，以及 Patrick Ohly，他是 Intel 的軟體工程師兼架構師，同時也是 SIG Testing 的技術負責人。
貢獻者簡介
Sandipan: 能否簡單介紹一下自己、你的角色，以及你是如何參與到 Kubernetes 專案和 SIG Testing 中的？
Michelle: 嗨！我是 Michelle，Google 的一名高階軟體工程師。我最初是透過為 SIG Testing 開發工具（如 TestGrid 的外部例項）而參與到 Kubernetes 中的。我是 TestGrid 和 Prow 的 oncall 團隊成員，現在是 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），以及 test-infra 倉庫中一系列用於分類、分析、覆蓋率、Prow/TestGrid 配置生成等的其他工具和實用程式。
如果你想了解更多並參與任何 SIG Testing 的子專案，請檢視 SIG Testing README。
主要挑戰與成就
Sandipan: 你們面臨的一些主要挑戰是什麼？
Michelle: Kubernetes 在各個方面都是一個巨大的專案，從貢獻者到程式碼再到使用者等等。測試和基礎設施必須滿足這種規模，跟上 Kubernetes 下每個倉庫的每一次變化，同時儘可能地促進專案的開發、改進和釋出，當然，我們不是唯一參與其中的 SIG。我認為另一個挑戰是子專案的人員配備。SIG Testing 有許多已經存在多年的子專案，但許多最初的維護者已經轉向其他領域或不再有時間維護它們。我們需要在這些子專案中培養長期的專業知識和負責人。
Patrick: 正如 Michelle 所說，龐大的規模可能是一個挑戰。這不僅是基礎設施的問題，我們的流程也必須隨著貢獻者數量的增加而擴充套件。記錄最佳實踐是好的，但這還不夠：我們有很多新貢獻者，這很好，但讓審查者解釋最佳實踐是不可擴充套件的——假設審查者們甚至知道這些實踐！現有程式碼無法立即更新也無濟於事，因為程式碼量太大了，尤其是在 E2E 測試方面。倡議對新程式碼或修改後的程式碼應用更嚴格的 lint 檢查，同時接受現有程式碼不透過這些相同的 linter 檢查，這有所幫助。
Sandipan: 有沒有什麼 SIG 的成就讓你們感到自豪並想重點介紹的？
Patrick: 我有偏見，因為我一直在推動這件事，但我認為 E2E 框架和 lint 檢查現在比以前好多了。我們可能很快就能在啟用競態檢測的情況下執行整合測試，這很重要，因為我們目前只對單元測試這樣做，而單元測試往往不那麼複雜。
Sandipan: 測試總是很重要，但就 Kubernetes 的釋出流程而言，你們的工作有什麼特別之處嗎？
Patrick: 測試不穩定（test flakes）……如果我們有太多這樣的情況，開發速度就會下降，因為 PR 在沒有乾淨的測試執行的情況下無法合併，而乾淨的測試執行變得越來越不可能。開發者們也會對測試失去信任，只是“重新測試”，直到他們得到一個乾淨的執行結果，而不檢查失敗是否確實與他們當前更改中的迴歸有關。
人員與範圍
Sandipan: 關於這個 SIG，你最喜歡的一些事情是什麼？
Michelle: 當然是人 🙂。除此之外，我喜歡 SIG Testing 廣泛的範圍。我覺得即使是微小的改變也能為其他貢獻者帶來巨大的不同，而且即使我的興趣隨著時間的推移而改變，我也永遠不會缺少可以工作的專案。
Patrick: 我可以從事那些能讓我和我的同行開發者生活更美好的事情，比如我們在其他地方開發新功能時每天都必須使用的工具。
Sandipan: 有沒有什麼有趣/酷/TIL（今天我學到了）的軼事可以告訴我們？
Patrick: 我五年前開始從事 E2E 框架的增強工作，然後有一段時間不那麼活躍。當我回來想測試一些新的增強功能時，我詢問了如何為新程式碼編寫單元測試，並被指向一些現有的測試，這些測試看起來有些熟悉，好像我以前見過它們。我查看了提交歷史，發現是我寫的！這說明了我的長期記憶力衰退還是這很正常，由你來決定……總之，夥計們，記得寫好提交資訊和註釋；總有人在某個時候需要它們——甚至可能是你自己！
展望未來
Sandipan: 你們的 SIG 在哪些領域和/或子專案上需要幫助？
Michelle: 有些子專案目前沒有人員配備，需要有人願意更多地瞭解它們。特別是 boskos 和 kubetest2，因為它們對測試很重要，但缺乏專門的負責人。
Sandipan: 新的 SIG Testing 貢獻者可以帶來哪些有用的技能？如果人們的背景與程式設計不直接相關，他們可以做些什麼來幫助這個 SIG？
Michelle: 我認為使用者同理心、寫出清晰的反饋和識別模式非常有用。一個使用測試框架或工具的人，能夠用清晰的例子概述痛點，或者能夠識別專案中更廣泛的問題並提取資料來為解決方案提供資訊。
Sandipan: SIG Testing 的下一步是什麼？
Patrick: 更嚴格的 lint 檢查很快將成為新程式碼的強制要求。有幾個 E2E 框架的子包可以進行現代化改造，如果有人願意承擔這項工作的話。我也看到了一個機會，可以統一我們的一些用於 E2E 和整合測試的輔助程式碼，但這需要更多的思考和討論。
Michelle: 我期待著為我們的一些工具和基礎設施做一些可用性改進，並支援更多的長期貢獻和貢獻者成長為 SIG 內的長期角色。如果你感興趣，就來找我們吧！
展望未來，SIG Testing 有著激動人心的計劃。你可以在他們的 Slack 頻道中與 SIG Testing 的成員取得聯絡，或者參加他們每兩週一次的週二例會。如果你有興趣讓社群更容易地執行測試和貢獻測試結果，以確保 Kubernetes 在各種叢集配置和雲提供商中保持穩定，今天就加入 SIG Testing 社群吧！