The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
几周前，我在Twitter上提出了这个想法，得到了大多数负面反应。这就是为什么我写了这篇博文，详细阐述这个主题，试图说服你。我建议的规则是：将代码的更改与其单元测试的更改分开提交。简单来说，在一个拉取请求中，你修改测试，可能标记其中一些为“禁用”。然后合并此拉取请求，然后进行第二个拉取请求，修改代码，很可能从测试中删除“禁用”标记。在第二个拉取请求中不要触及测试的主体部分。
这可能看起来与TDD原则相矛盾。然而，对我来说，这种方法看起来更像是对TDD的极端应用，而不是违反它。首先，我们合并测试，这很可能会导致构建失败，因为它们所测试的功能尚不存在。为了避免构建失败的状态，我们禁用了我们添加的新测试和修改的测试。例如，在JUnit 5中，我们使用@Disabled注解来实现此功能。
评审人员会验证你所做的更改，并问自己以下问题：“我们真的需要这个新功能吗？它是否与现有功能冲突？用这种特定方式测试新功能是否有意义？”他们不考虑功能的实现方式，只关心你在测试中对产品所提出的要求。评审人员在这个阶段更多地充当需求工程师的角色。他们验证意图，而不是实现。
然后，在第二个拉取请求中，你修改代码而不触及测试。现在，评审人员可以放心，你没有仅仅为了让要求更适合你的实现而改变要求。换句话说，他们知道你没有作弊。由于你没有触及测试，评审人员可以确保要求保持稳定，你只修改了实现。用商业语言来说，如果/当你发现无法交付所承诺的内容时，你不会改变合同。
此外，当你仅修改测试而不触及代码时，评审人员更容易理解你的更改是否真正属于你应该解决的问题。我们程序员往往犯一个典型的错误：我们修改代码，一些测试失败，我们修复测试…无论它们是“我们”的测试还是其他测试。我们只是让测试通过，而不管它们失败的原因。我们不是在倾听它们，而是把它们给堵住。稍后，评审人员可能不明白为什么有些测试被修改了。尤其是如果拉取请求很大的话。他们很可能会盲目地相信你并合并拉取请求。
这就是为什么将测试与代码分开的解决方案。首先，修改测试，评审人员只关注测试的范围。如果更改范围过于广泛，与你正在解决的问题无关，他们将很容易发现。然后修改代码，评审人员完全不需要担心测试。他们不关注测试，只审查实现。他们知道你不能破坏测试，因为构建流水线不允许你这样做。
你现在有什么想法？这样做有意义吗？
Translated by ChatGPT gpt-3.5-turbo/42 on 2024-01-09 at 18:10
