编写实现后如何纠正测试中的错误

如果正确实施逻辑后，测试仍然失败（因为测试中有错误），则TDD中的最佳措施是什么？

例如，假设您要开发以下功能：

int add(int a, int b) {
    return a + b;
}

假设我们按照以下步骤进行开发：

1. 编写测试（尚无功能）：

   // test1
   Assert.assertEquals(5, add(2, 3));
   

   导致编译错误。

2. 编写一个虚拟函数实现：

   int add(int a, int b) {
       return 5;
   }
   

   结果：test1通过。

3. 添加另一个测试用例：

   // test2 -- notice the wrong expected value (should be 11)!
   Assert.assertEquals(12, add(5, 6));
   

   结果：test2失败，test1仍然通过。

4. 编写实际的实现：

   int add(int a, int b) {
       return a + b;
   }
   

   结果：test1仍然通过，test2仍然失败（因为11 != 12）。

在这种特定情况下：

1. 更正test2，看看它现在通过了，或者
2. 删除实现的新部分（即返回上面的步骤2），更正test2并使其失败，然后重新引入正确的实现（上面的步骤4）。

还是还有其他更聪明的方法？

虽然我知道示例问题相当琐碎，但我对通用情况下的操作很感兴趣，这可能比两个数的加法复杂。

编辑（响应@Thomas Junk的回答）：

这个问题的重点是在这种情况下TDD提出的建议，而不是实现良好代码或测试（可能与TDD方式不同）的“通用最佳实践”。

绝对关键的是，您会看到测试通过和失败。

删除代码以使测试失败然后重写代码还是将其潜入剪贴板，然后再粘贴回去都无所谓。TDD从未说过您必须重新输入任何内容。它想知道测试仅在应通过时通过，而仅在应通过时失败。

看到测试通过和失败都是您测试测试的方式。永远不要相信您从未见过的一项测试。

针对红条进行重构为我们提供了重构工作测试的正式步骤：

• 运行测试
  • 注意绿色栏
  • 破坏正在测试的代码
• 运行测试
  • 注意红色条
  • 重构测试
• 运行测试
  • 注意红色条
  • 破解正在测试的代码
• 运行测试
  • 注意绿色栏

但是，我们不会重构工作测试。我们必须改造一个越野车测试。一个令人关注的问题是，仅在此测试涵盖的范围内引入了代码。修复测试后，应回滚并重新引入此类代码。

如果不是这种情况，并且由于其他测试覆盖了代码，那么代码覆盖率也不是问题，您可以转换该测试并将其引入为绿色测试。

在这里，代码也被回滚，但是刚好足以导致测试失败。如果这还不足以涵盖所有引入的代码，而仅由越野车测试覆盖，则我们需要更大的代码回滚和更多测试。

进行绿色测试

• 运行测试
  • 注意绿色栏
  • 破坏正在测试的代码
• 运行测试
  • 注意红色条
  • 破解正在测试的代码
• 运行测试
  • 注意绿色栏

破坏代码可以是注释掉代码，也可以将其移到其他位置以供稍后粘贴回去。这向我们展示了测试涵盖的代码范围。

对于这最后的两次运行，您将回到正常的红色绿色循环。您只是粘贴而不是键入内容来破坏代码并通过测试。因此，请确保您仅粘贴了足以使测试通过的内容。

这里的总体模式是查看测试的颜色改变我们期望的方式。请注意，这会造成您短暂进行不受信任的绿色测试的情况。请小心不要被打扰，并忘记您在这些步骤中的位置。

感谢RubberDuck的“ 拥抱红色条形”链接。

您要实现的总体目标是什么？

• 做好的测试？

• 进行正确的实施？

• 虔诚地做TTD 对吗？

• 以上都不是？

也许您过分考虑了与测试和测试之间的关系。

测试不能保证实现的正确性。通过所有测试后，您的软件是否执行应做的事情就什么也没有。它对您的软件不做任何实质性陈述。

以您的示例为例：

添加的“正确”实现将是等效于的代码a+b。而且只要您的代码能够做到，您就可以说算法是正确的，并且可以正确实现。

int add(int a, int b) {
    return a + b;
}

在第一眼，我们都同意，这是一个另外的实施。

但是我们实际上并不是在说，这段代码只是addition它的实现，在某种程度上表现得像一个：想想整数溢出。

整数溢出确实会在代码中发生，但不会在中出现addition。因此：您的代码在某种程度上的行为类似于的概念addition，但不是addition。

这种颇为哲学的观点具有若干后果。

一个就是，您可以说，测试不过是对代码预期行为的假设。在测试代​​码时，您可能（也许）永远无法确保自己的实现是正确的，最好的说就是，您对代码交付的结果的期望是否得到满足；是，您的代码是错误的，还是您的测试是错误的，还是它们都是错误的。

有用的测试可以帮助您确定对代码应该做什么的期望：只要我不改变期望，并且只要修改后的代码能够为我带来期望的结果，就可以肯定，我所做的假设结果似乎可以解决。

当您做出错误的假设时，这无济于事。但是，嘿！至少它可以预防精神分裂症：当没有结果时会期待不同的结果。

tl; dr

如果正确实施逻辑后，测试仍然失败（因为测试中有错误），则TDD中的最佳措施是什么？

您的测试是关于代码行为的假设。如果您有充分的理由认为自己的实现是正确的，请修复测试并查看该假设是否成立。

您需要知道，如果实现错误，则测试将失败，这与实现正确的情况与通过测试不同。因此，您应该在更正测试之前将代码放回预期失败的状态，并确保其失败是由于您期望的原因（例如5 != 12），而不是您未曾预料到的其他原因。

在这种特殊情况下，如果您将12更改为11，并且现在测试通过了，我认为您已经很好地测试了测试以及实现，因此不需要太多麻烦。

但是，在更复杂的情况下（例如，您的设置代码有误）也会出现相同的问题。在这种情况下，修复测试后，您应该尝试以某种方式使实现变异，以使特定测试失败，然后还原变异。如果还原实现是最简单的方法，那很好。在您的示例中，您可能会a + b更改为a + a或a * b。

另外，如果您可以稍微更改断言并看到测试失败，则可以非常有效地测试测试。

我会说，这是您最喜欢的版本控制系统的一种情况：

1. 进行测试的更正，将代码更改保留在工作目录中。
   提交相应的消息Fixed test ... to expect correct output。

   使用git，这可能需要使用git add -p测试和实现是否在同一个文件中，否则显然您可以将两个文件分别暂存。

2. 提交实现代码。

3. 及时返回以测试步骤1中所做的提交，确保测试实际上失败了。

您会看到，这样一来，您在测试失败的测试时就不会依赖编辑能力来将实现代码移开。您可以使用VCS来保存您的工作，并确保VCS记录的历史记录正确地包括失败测试和通过测试。