本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
聚焦 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 社区吧！