本文已超过一年。较旧的文章可能包含过时内容。请检查页面信息自发布以来是否已变得不准确。
聚焦 SIG Testing
欢迎阅读新一期《SIG 聚焦》博客系列，我们在其中重点介绍 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：您好！我是 Google 高级软件工程师 Michelle。我最初参与 Kubernetes 是通过研究 SIG Testing 的工具，例如 TestGrid 的外部实例。我是 TestGrid 和 Prow 值班团队的一员，现在是该 SIG 的主席。
Patrick：您好！我在 Intel 的一个团队担任软件工程师和架构师，该团队专注于开源云原生项目。当我开始深入研究 Kubernetes 以开发存储驱动程序时，我的第一个问题是“如何在集群中测试它以及如何记录信息？” 这种兴趣促使我提交了各种增强提案，直到我编写了足够多的代码，并承担了 SIG Testing 技术负责人（负责 E2E framework）和结构化日志记录工作组负责人的官方角色。
测试实践与工具
Sandipan：测试是一个存在多种方法和工具的领域；你们是如何形成当前的实践的？
Patrick：我无法谈论早期，因为那时我还没加入 😆，但回顾一些提交历史，很明显开发者只是拿来了现有的东西并开始使用它们。对于 E2E 测试，那就是 Ginkgo+Gomega。一些必要的 hack 是需要的，例如关于测试运行后的清理和测试分类。最终这导致了 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 测试方面。对新代码或修改后的代码应用更严格的 linting，同时接受现有代码不通过相同 linter 检查的倡议，有所帮助。
Sandipan：有没有什么让你们引以为豪并想重点介绍的 SIG 成就？
Patrick：我可能会有偏见，因为我一直负责这项工作，但我认为 E2E framework 和 linting 现在比以前好多了。我们可能很快就能启用竞态检测来运行集成测试，这很重要，因为目前我们只在单元测试中实现了这一点，而单元测试通常不太复杂。
Sandipan：测试始终很重要，但在 Kubernetes 发布流程方面，你们的工作有什么特别之处吗？
Patrick：测试不稳定 (test flakes)……如果我们有太多这样的测试，开发速度就会下降，因为 PR 无法在测试干净运行的情况下合并，而干净运行的可能性会降低。开发者也会失去对测试的信任，只是不断“重试”，直到获得干净运行，而没有检查失败是否确实与他们当前更改中的回归有关。
人员与范围
Sandipan：这个 SIG 最让您喜欢的地方有哪些？
Michelle：当然是人 🙂。除此之外，我喜欢 SIG Testing 广泛的范围。我觉得即使是很小的改变也能对其他贡献者产生重大影响，而且即使我的兴趣随时间变化，我也永远不会没有项目可做。
Patrick：我可以致力于改善我自己和我的其他开发者生活的事情，比如我们在开发其他新功能时每天必须使用的工具。
Sandipan：有什么有趣/酷/TIL（今日学到）的趣闻可以分享吗？
Patrick：我五年前开始致力于 E2E framework 增强，然后有一段时间在那里不那么活跃。当我回来想测试一些新的增强时，我询问如何为新代码编写单元测试，然后被指引到一些看起来有点熟悉的现有测试，仿佛我以前见过它们一样。我查看了提交历史，发现竟然是我写的！我让你们来判断这是否说明我的长期记忆力衰退了，还是这只是正常情况……总之，伙计们，记住写好的提交消息和注释；迟早会有人需要它们——甚至可能是你自己！
展望未来
Sandipan：你们的 SIG 在哪些领域和/或子项目上需要帮助？
Michelle：一些子项目目前人手不足，需要愿意深入了解它们的人。boskos 和 kubetest2 对我来说尤其突出，因为两者都对测试很重要，但缺乏专门的所有者。
Sandipan：SIG Testing 的新贡献者可以带来哪些有用的技能？如果他们没有直接与编程相关的背景，他们可以做些什么来帮助这个 SIG？
Michelle：我认为用户同理心、编写清晰的反馈以及识别模式都非常有用。比如使用测试框架或工具并能通过清晰的例子概述痛点的人，或者能够识别项目中的更广泛问题并提取数据来为解决方案提供信息的人。
Sandipan：SIG Testing 的下一步是什么？
Patrick：更严格的 linting 将很快成为新代码的强制要求。有几个 E2E framework 子包可以进行现代化改造，如果有人愿意承担这项工作。我还看到了一个机会，可以统一我们用于 E2E 和集成测试的一些辅助代码，但这需要更多的思考和讨论。
Michelle：我期待着对我们的一些工具和基础设施进行可用性改进，并支持更多长期贡献以及贡献者成长为 SIG 内的长期角色。如果您有兴趣，请联系我们！
展望未来，SIG Testing 有令人兴奋的计划。您可以在他们的 Slack 频道 联系 SIG Testing 的成员，或参加他们常规的每两周一次的周二会议。如果您有兴趣让社区更容易运行测试和贡献测试结果，以确保 Kubernetes 在各种集群配置和云提供商中稳定运行，请立即加入 SIG Testing 社区！