防止逻辑缺陷

我们从痛苦的经验中知道，最简单的逻辑错误往往最容易产生。我们都能联想到的例子包括那些一次性错误、未初始化变量导致的 NullPointerException，以及文档中未提及的库抛出的异常。它们都非常简单和小巧。似乎我们应该很容易意识到自己在犯这些错误，但我们都知道它们往往是最难发现的。当我们人类专注于代码的大局时，有时这些关键细节就会被忽视。

我们知道手动测试可以揭示这些逻辑缺陷，但我们也从经验中知道，手动测试计划是脆弱的。可能会遗漏步骤，或者匆忙中错过重要错误。我们可能会简单地假设某个部分在这个版本中不需要测试，因为我们没有更改那部分代码。你猜对了——这并不总是对我们有利。如果某些底层假设发生了变化，错误可能会出现在看似与错误完全无关的代码部分。

手动测试需要花钱，而这些钱现在不能用于添加闪亮的新功能。

手动测试还被指责为延迟发布日期的原因。这对我们的手动测试同事来说是非常不公平的。开发团队——显然在没有 TDD 测试的情况下编写代码——在自己的错误中挣扎，直到只剩下几天时间发布。然后，我们将代码交给测试人员，他们必须在几乎没有时间的情况下运行一个庞大的测试文档。他们有时会被指责为延迟发布的原因，尽管真正的原因是开发时间比预期长。

然而，我们从未真正有过发布。如果我们将发布定义为包括经过测试的代码（我们应该这样做），那么很明显，必要的测试从未发生过。当你甚至不知道代码是否有效时，你不能道德地发布代码。如果你这样做了，你的用户会很快抱怨。

难怪我的一些测试同事在冲刺(sprint)结束时变得如此暴躁。

TDD 完全涵盖了这一点。这些逻辑错误根本无法出现，这听起来像是幻想，但它确实是真的。

在你输入任何生产代码之前，你已经编写了一个失败的测试。一旦你添加了新代码，你重新运行测试。如果你在代码中输入了逻辑错误，测试仍然失败，你会立即知道。这就是魔法：你的错误发生了，但立即被突出显示。这使你能在脑海中记忆犹新时修复它。这也意味着你不会忘记稍后修复它。

你通常可以找到错误的确切行并进行更改。这是 10 秒钟的工作，而不是等待测试团队工作并填写 JIRA 错误票的几个月时间。

我们谈论的这种单元测试运行速度也非常快——非常快。许多测试在毫秒内运行。将其与编写测试计划文档、运行整个应用程序、设置存储数据、操作用户界面（UI）、记录输出然后填写错误票的总时间进行比较。这是无可比拟的更好，不是吗？

你可以看到这是一个消灭错误的超能力。我们在代码-测试-调试周期中节省了大量时间。这降低了开发成本并提高了交付速度。这对我们的团队和用户来说都是巨大的胜利。

每次你在编写代码之前编写测试时，你已经将错误排除在该代码之外。你遵循最基本的规则：你不检查带有失败测试的代码。你让它们通过。

这不应该需要说，但你也不应该通过删除测试、忽略测试或使用某种技术手段使测试始终通过来绕过失败的测试。然而，我说这些是因为我在实际代码中看到过这种情况。

我们已经看到先编写测试如何帮助防止在新代码中添加错误，但 TDD 甚至比这更好：它有助于防止在未来添加的代码中添加错误，我们将在下一节中介绍这一点。