关于 TDD 的常见误解

我自己也这么说过。我曾经认为，我只需要尽可能快地写出解决方案代码，手动测试一下，然后让测试部门确保一切构建正确。这可能是我对 TDD 最严重的误解。作为软件开发人员，我们开发软件是为了解决问题。如果我们开发人员造成了更多的问题，那么我们就没有尽到自己的职责。

如果你是第一次听到这种说法，我会感到很惊讶。我最初是从一个有技术背景的客户那里听说的，而不是从一个开发人员那里。我自己并不喜欢 TDD，而且当时也同意客户的观点。当然，把测试代码和解决方案代码写在一起会慢一些，毕竟我需要在键盘上输入更多的字符！

在企业项目中，根据我的经验，TDD 使我们免于数月的错误和回归。第 5 章 "单元测试" 将讨论编写测试和良好的测试覆盖率，这将有助于确保下次别人修改代码或添加新功能时，不会出现回归。TDD 将帮助你建立大量的自动测试，与将未经测试的解决方案代码交给测试团队或测试公司进行人工测试相比，运行这些测试的成本更低，速度更快。

TDD 不是为现有功能编写自动测试或单元测试。TDD 不是让你的 QA 部门或第三方公司为现有软件编写自动化测试。这与 TDD 恰恰相反。我观察到的最常见的误解是，一些开发人员和测试人员认为 TDD 与测试人员为开发人员构建的代码编写自动化测试有关。我认为这是一个非常糟糕的误解。这与开发一个程序并将其交给质量保证部门进行人工测试没有什么区别。

让测试人员编写自动化功能测试是一件非常好的事情，尤其是对于没有自动化测试的现有功能，但这只应被视为软件测试覆盖范围的补充，而不应与 TDD 混为一谈。

我遇到的最后一个误解是，如果我们开发人员按照 TDD 方法建立了出色的测试覆盖率，我们就不再需要软件开发部门和质量保证部门或团队的投入了。我一次又一次地证明自己错了，我认为通过 TDD 方法编写的代码是防不胜防的。我很幸运能与知识渊博、技术精湛的软件工程师和测试工程师共事。代码评审 至关重要；代码和测试方案一定要经过同行评审。开发人员可能忽略的边缘情况测试和功能场景会造成问题，而根据我的经验，它们已经造成了大问题。

对于开发和测试团队来说，正确理解功能和验收测试用例非常重要，这样才能涵盖所有可以想象到的情况：第 5 章 "单元测试" 将介绍不同类型的测试。这就是行为驱动开发（BDD）的意义所在；第 6 章 "应用行为驱动开发" 将对 BDD 进行更详细的讨论。我曾与测试工程师和质量保证人员共事，他们能提出我无法想象的边缘案例。

我们已经讨论了我遇到的关于 TDD 的一些常见误解。现在，让我们试着说明为什么要考虑在开发过程中使用 TDD。