问为什么单元测试失败被认为是糟糕的？

EN

这个问题包含了IMHO的几个误解，但我想集中讨论的主要问题是，它没有区分本地开发分支、主干、分期或发布分支。

在本地开发分支中，几乎在任何时候都可能有一些失败的单元测试。在后备箱中，它只能在某种程度上被接受，但它已经成为尽快修复事物的有力指标。请注意，主干中失败的单元测试可能会干扰团队的其他部分，因为它们要求每个人检查是否他/她最近的更改导致了失败。

在分阶段或发布分支中，失败的测试是“红色警报”，表明当某些更改集从主干合并到发布分支时出现了完全错误。

我甚至建议，即使是发布失败的单元测试的软件也不是必要的坏。

使用某些已知的bug发布低于一定严重程度的软件并不一定是坏事。然而，这些已知的故障不应导致单元测试失败。否则，在每次单元测试运行之后，人们将不得不查看20个失败的单元测试，并逐一检查故障是否是可接受的。这会变得麻烦，容易出错，并抛弃了单元测试自动化方面的很大一部分。

如果您确实有可接受的已知错误的测试，请使用您的单元测试工具的禁用/忽略特性(因此它们在默认情况下不会运行，只是按需运行)。此外，添加一个低优先级的票到你的问题跟踪器，这样问题就不会被遗忘。

..。所有单元测试都是绿色的--这应该是好的。

这很好。不是“应该是的”。

它提倡了这样一种观点:代码应该是完美的，不应该存在bugs -在现实世界中，对于任何大小的程序来说，这都是不可能的。

不是的。它证明了您已经尽了最大的努力测试了代码。您的测试完全有可能不涵盖每一种情况。如果是这样的话，任何错误最终都会出现在bug报告中，您将编写失败测试来重现问题，然后修复应用程序，以便测试通过。

想出会失败的单元测试是一种抑制因素。

不合格或不合格的测试对您的应用程序将接受和不接受的内容设置了严格的限制。我所知道的大多数程序都会反对2月30日的“日期”。另外，我们这些有创造力的开发人员也不想破坏“他们的孩子”。由此产生的对“幸福之路”案例的关注会导致脆弱的应用程序经常崩溃。

要比较开发人员和测试人员的心态：

• 一旦代码完成了他们想要的，开发人员就会停止。
• 当测试程序不能再使代码中断时，测试程序就会停止。

这些是完全不同的观点，对许多开发人员来说是很难调和的。

或者一定要想出一些很难修复的单元测试。

你不会为了自己而写测试。您可以编写测试，以确保您的代码正在做它应该做的事情，更重要的是，在您更改了它的内部实现之后，它继续执行它应该做的事情。

• 调试“证明”代码可以实现您今天想要的结果。
• 测试“证明”，随着时间的推移，代码仍然按照您的要求执行。

如果在任何时间点上所有单元测试都通过，那么在任何时间点上都没有软件状态的大图。没有路线图/目标。

唯一的“图片”测试提供给您的是代码在测试时“工作”的快照。在那之后，它是如何进化的，这是另一个故事。

它阻止了在实现之前编写单元测试。

这正是你应该做的。编写一个失败的测试(因为它正在测试的方法还没有实现)，然后编写方法代码来使方法工作，从而使测试通过。这几乎是测试驱动开发的关键所在。

我甚至建议，即使是发布失败的单元测试的软件也不是必要的坏。至少你知道软件的某些方面是有局限性的。

释放带有中断测试的代码意味着其功能的某些部分不再像以前那样工作。这可能是故意的行为，因为您已经修复了一个bug或增强了一个特性(但是您应该首先更改测试，使其失败，然后编写修复/增强代码，使测试在过程中工作)。更重要的是:我们都是人，我们都会犯错。如果你破坏了代码，那么你应该破坏测试，而那些坏掉的测试应该会敲响警钟。

这不是生活在梦幻世界吗？

如果有的话，那就是生活在现实世界，承认开发人员既不是无所不知的，也不是无懈可击的，我们确实会犯错误，如果我们真的搞砸了，我们需要一个安全网来抓我们！

进入测试。

这难道不妨碍对代码的真正理解吗？

也许吧。您不一定需要理解某些东西的实现才能为它编写测试(这是它们的一部分)。测试定义应用程序的行为和限制，并确保这些行为和限制保持不变，除非您有意更改它们。

为什么单元测试失败被认为是糟糕的？

它们不是--测试驱动的开发是建立在失败测试的概念之上的。失败的单元测试驱动开发，失败的验收测试来驱动一个故事.

您缺少的是上下文；单元测试在哪里允许失败？

通常的答案是，单元测试只允许在私有沙箱中失败。

基本概念是:在共享失败测试的环境中，需要额外的努力才能了解产品代码的更改是否引入了新的错误。零和非零之间的差异比N和N之间的差异更容易检测和管理。

此外，保持共享代码的整洁意味着开发人员可以继续执行任务。当我合并您的代码时，我不需要将上下文从我要解决的问题转移到校准我对应该失败多少个测试的理解上。如果共享代码通过了所有测试，那么当我在更改中合并时出现的任何故障都必须是代码与现有干净基线之间交互的一部分。

类似地，在登陆过程中，新开发人员可以更快地提高效率，因为他们不需要花时间去发现哪些失败的测试是“可以接受的”。

更准确地说:规则是在构建过程中运行的测试必须通过。

据我所知，失败的测试是禁用的，这是没有问题的。

例如，在“持续集成”环境中，您将在高节奏上共享代码。集成通常并不一定意味着您的更改必须发布就绪。有各种各样的黑暗部署技术可以防止通信被释放到代码的各个部分，直到它们准备好为止。

同样的技术也可以用于禁用失败的测试。

我在一个点版本上进行的练习之一是处理一个有许多失败测试的产品的开发。我们想出的答案是简单地通过套件，禁用失败的测试并记录每个测试。这使得我们能够迅速地达到所有已启用的测试都已通过的程度，管理/目标捐赠者/黄金所有者都可以看到我们为达到这一目标所做的交易，并且可以对清理和新工作做出明智的决定。

简而言之:除了在运行套件中留下一堆失败的测试之外，还有其他跟踪工作没有完成的技术。