What Do Contribution Guidelines Say About Software Testing?

请将开源软件项目想象成规模宏大、繁忙有序的社区厨房。任何人都可以走进厨房，拿起一把菜刀并开始切菜（编写代码），以帮助烹饪出一道更好的佳肴。但为了让厨房顺畅运转，主厨们（项目维护者）会在柜台上留下一本**“规则手册”**。这本手册会告诉新来的帮手如何洗手、在哪里寻找食材，以及如何提交他们切好的蔬菜而不弄坏整锅汤。

这篇文章就像是一支研究团队，他们走进了 200 个这样著名的社区厨房（具体是使用 Python 和 JavaScript 语言的项目），阅读了这些规则手册，并观察其中关于**测试（testing）**的内容究竟写了什么。

在烹饪的世界里，“测试”就像是在上菜前品尝一下菜肴，以确保它尝起来不会有肥皂味。研究人员想知道：这些规则手册是否真的教会了新来的帮手如何品尝食物，还是仅仅假设每个人都已经懂得如何做了？

以下是他们的发现，通过简单的分类呈现如下：

1. 大多数厨房都有“品尝”环节（但并非全部）

研究人员发现，78% 的厨房在他们的规则手册中专门设有关于品尝（测试）的部分。

• 它在哪里？ 大多数情况下（5 8%），它位于名为“CONTRIBUTING”（贡献指南）的文件中（即主要说明手册）。有时它会在一份单独的、精致的小册子（外部文档）中，极少数情况下则只是随手写在主菜单（README）上。
• 差距： 约 22% 的厨房完全没有关于品尝的说明。如果你走进那些厨房，你必须靠猜来判断你的食物味道是否合格。

2. “如何做”的不平衡：运行 vs. 编写

当规则手册确实谈到品尝时，它们擅长一件事，却不擅长另一件事。

• “如何运行”（83.5%）： 大多数规则手册都清晰地说明了：“这是检查整锅汤味道的魔法咒语（命令）。” 这就像是在说：“按下这个按钮来检查味道。”
• “如何编写”（37%）： 只有极少数规则手册解释了如何实际创造一个新的味觉测试。这就像是说：“按下这个按钮，”却没教你如何制作一把新勺子，或者如何辨别什么是“不好”的味道。
• 结果： 帮手们知道如何检查现有的食物，但在如何为他们添加的新食材创建自己的测试时，往往只能靠猜。

3. “测试金字塔”问题

在软件领域，存在不同层级的测试，就像不同类型的味觉测试一样：

• 单元测试 (Unit Tests) (71%)： 这些就像品尝单一食材（例如：“这根胡萝卜甜吗？”）。规则手册经常提到这一点。
• 集成测试 (Integration Tests) (20.5%)： 这些就像品尝胡萝卜和洋葱在锅里结合后的味道。规则手册很少提到这一点。
• 端到端测试 (End-to-End Tests) (15.5%)： 这就像是品尝最后完成的整道菜，看看整个菜肴是否运作正常。规则手册几乎从未谈及此事。

隐喻： 厨师们非常担心胡萝卜的味道是否正确，但他们很少告诉帮手如何检查整锅炖菜是否会烧焦，或者各种味道是否融合得好。

4. 缺失的“秘密武器”

研究人员还寻找了一些能让测试变得更容易、更可靠的高级烹饪技巧：

• 模拟 (Mocking) (9.5%)： 有时，你无法在汤里品尝到真正的海水；你必须使用一个假的盐罐来模拟它。这就是所谓的“模拟”。只有十分之一的厨房提供了关于如何使用这些虚拟工具的说明。
• 覆盖率 (Coverage) (25.5%)： 这是一张计分卡，显示了有多少比例的食谱实际上被品尝过了。只有大约四分之一的厨房告诉了帮手他们应该追求什么样的分数。
• 最佳实践 (Best Practices) (9%)： 比如“始终在出餐前品尝”这类通用建议非常罕见。

核心结论

本文结论指出，虽然大多数开源项目希望其帮手能够测试他们的工作，但它们留下的指令是不平衡的。

它们非常擅长表达“如何运行测试”，但在以下方面往往保持沉默：

• 如何编写一个新的测试。
• 如何测试复杂的交互作用（集成测试）。
• 如何测试整个系统（端到端测试）。
• 如何使用高级工具（模拟）或设定质量目标（覆盖率）。

启示： 如果你是这些厨房中的一名新帮手，你可能知道如何按下“品尝”按钮，但对于如何为你的新食谱创建一个味觉测试，或者如何确保你的新菜肴不会毁掉整顿饭，你可能会感到无所适从。作者建议，项目领导者需要编写更清晰、更完整的指令，以免让帮手们只能靠猜。