当新功能导致现有单元测试失效时该怎么办？

Question

我正在构建一个新的应用程序，并尽可能忠实地坚持“测试优先”的开发。我发现自己处于需要实现/更改具有使许多现有单元测试无效的功能的情况。我该怎么处理这件事？在我看来，有3个选项：

• 更新或删除所有现有测试以满足新功能要求（根据需要添加更多），然后实现该功能

• 首先实施该功能，运行测试以查看失败，并更新或删除任何失败的测试（根据需要添加更多）

• 为新功能添加新测试， 实现该功能，运行所有测试 看到旧的失败，删除或 根据需要更新旧测试

第一种选择坚持TDD，但可能会产生极大的反效果。第二种选择是最简单的，但你不会先忠实地测试，也可能没有被“覆盖”。第三种选择是对两者的妥协，并且在某种程度上具有吸引力，但是当你刚刚更新旧版本时，你可能会重新编写测试。

我觉得我没有任何明确的策略。你在这些情况下做了什么？

Answer 1

我会选择一个测试并将其更改为需要新功能。如果没有任何明显的候选人，即它真的是新的，我会创建一个。然后我会编写代码来通过该测试。那时我会运行我的其他测试，并注意到其中一些测试失败了。此时，我将依次重新检查每个测试，或者更正测试以反映新功能（因此它将在没有其他代码更改的情况下通过）或者更新关于新功能的测试（这可能需要对其进行一些进一步的更改）正在测试的代码。）

Answer 2

我会为新功能创建新测试，并更新现有测试以适应您的功能。如果你打破了已经在工作的测试，你应该修复它。

Answer 3

实现功能包括编写/更新单元测试;这是测试驱动开发的基础。所以你的第二个选项也是TDD，而不仅仅是你的第一个。在实践中，我怀疑你会想要你的第三个选项有一些mods：

1. 为该功能编写测试（因为这可以帮助您验证API / UI）
2. 编写功能
3. 审核该常规区域的单元测试，以查看
4. 运行测试
5. 修复那些中断的内容，如果＃3列表中没有任何中断，请修复它们（它们应该已经坏了）。如果有任何您未识别出来的情况，请进行调查，以确保其实际上是正确的 - 根据需要修复测试或功能。
6. 利润; - ）

Answer 4

我认为所有方法都是合理的。你会得到相同的结果。

有些人喜欢较小的步骤，并且在TDD的原始意图中工作更多：写一行测试，编写一行代码来修复它，重复。如果是这样的话，请先对旧测试进行逐步处理，然后将它们移植到新系统中。

如果你不介意咬掉更大的一块，那就深入研究一下。我发现这更自然，特别是在结对编程的时候，你可以更加大胆。

可能真的取决于你的舒适度和自信心。

我认为理想情况下，一个更改应该只打破一个测试，因此您可能希望重构测试代码，以便这就是您的行为。某种共享设置方法可能是解决方案。

Answer 5

摆脱旧测试并编写新测试。你可以在一些地方借用旧测试中的代码，但是你最好根据你想要做的事情进行测试，而不是尝试改变旧测试的性质。

测试是为了支持你想要完成的事情，不应该对你不利。

Answer 6

我认为这里有两件事需要考虑。我不知道你是否只想到其中一个或两个。

第一部分是您更改了一个功能，因为规范（或预期的行为）发生了变化。在这种情况下，我认为正确的做法是删除描述不再有效的行为的所有测试。因为我很懒，所以我只是评论它们或者暂时跳过它们。然后我将开始编写新测试（或取消注释/修改旧测试）以开始描述新行为直到完成。

如果您的新功能更改了其他组件使用的界面并且他们的测试因为您更改了功能而开始失败，则第二部分必须执行此操作。在这种情况下，我只需在功能完成后修复测试。