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/35 on 2023-09-08 at 16:10
