测试驱动的开发-说服我！[关闭]

我知道有些人大力支持测试驱动的开发。我过去曾使用过单元测试，但仅用于测试可以轻松测试的操作，或者我认为很可能是正确的操作。完整或接近完整的代码覆盖范围听起来会花费很多时间。

1. 您将测试驱动的开发用于哪些项目？您是否仅将其用于特定大小以上的项目？
2. 我是否应该使用它？说服我！

好的，TDD有一些优点：

1. 这意味着您需要进行更多测试。每个人都喜欢进行测试，但是很少有人喜欢编写测试。将测试编写写入开发流程中意味着您将获得更多测试。
2. 写测试会迫使您考虑设计的可测试性，而可测试的设计几乎总是更好的设计。我尚不完全清楚为什么会发生这种情况，但是我的经验以及大多数TDD宣传人员的经验似乎都可以证明这一点。
3. 一项研究表明，尽管TDD编写需要花费更长的时间，但由于您可以获得更高质量的代码，因此可以减少较少的错误，因此投资回报率很高。
4. 它使您对重构充满信心。能够更改一个系统而不必担心破坏其他所有系统，这是一种很棒的感觉，因为单元测试已经很好地覆盖了它。
5. 您几乎永远不会遇到重复的错误，因为找到的每个人都应该在得到修复之前进行测试。

您要求说服，所以这些都是好处。有关更平衡的观点，请参见此问题。

罗伯特·马丁（Robert C. Martin）最初提出这些观点-我可以根据自己的经验进行支持：

• 进行时，您将自动构建单元测试的回归测试套件。
• 您几乎不会花时间进行调试，就好像您自己编写代码一样，将您的代码撤消到最后一次测试通过时更容易，而不是打开调试器。
• 每隔几分钟，您就会验证自己的代码是否有效-全部（或至少测试涵盖的所有行为，如果执行的是TDD，则占很大比例）。

无论我是从事生产还是播放代码，我几乎总是在做TDD。我发现这些天很难用其他任何方式编写代码。

（免责声明：我几乎不做任何UI事情，所以我不能讨论UI的TDD。）

从琐碎的应用程序到整个SIP堆栈，我几乎在所有工作中都使用TDD。

我没有在接手的旧版PHP网站中使用TDD。没有测试我感到很痛苦。而且我发现它很烦人，意外破坏了网站的某些部分，因为我没有回归测试套件告诉我我破坏了一些东西。客户没有足够的预算来我（a）为代码库编写测试，并且（b）在此过程中首先使代码可测试，因此我忍受了。

• 只要能更有效地为您的客户提供服务（他们可能与测试有很好的联系-至少可以减少项目结束时的讨论）
• 每当需要花费更多时间让您的共同开发人员了解代码中的所有内容，而不是花精力进行测试时，这比您想像的要早

什么？没有否定的答案！？

免责声明：我不是反单元测试。当人们说TDD时，我假设他们指的是听起来有些病的版本，他们在写代码之前写测试，占所有写代码的80-100％。

我会争辩：

• 它是一个推动者。如果发现回归问题对您来说是一个巨大的问题，那么从一开始就进行全自动TDD似乎是值得的，那么对您编写的每段最后一段代码进行测试，实际上可能会帮助您忽略真正的问题。

• 它可以帮助人们忽略真正的问题。修复一个漏洞后，又出现了一个弹出式漏洞游戏，又弹出了两个漏洞，该体系结构开始崩溃。焦点。关注真正的问题。在必须对它们进行重击之前先看它们是很整洁的事情，但是您首先不应该在那里。

• 它花费很多时间。我偶尔遇到错误。我的命中率并不高，因此似乎值得在我编写的每件新事物上加一个测试。在可能发生的地方捕获问题。处理错误，以便易于诊断。验证。在重叠/瓶颈的关键点进行测试。但是，要大声喊叫，不要测试所有最后的吸气剂和吸气剂，而这些东西本来就不应该具有。

• 设计重点：即使是优秀的开发人员，也绝对不可能在专注于测试的同时编写他们可能会写的最好的代码。如果这似乎是进行体面设计的唯一途径，则建议您参阅上面的“专注于实际问题”。

• 宏设计失败：当前工作的代码库中充斥着从未使用过一次的接口，以及对基本DRY原理的大规模违反，当我意识到人们在为测试框架和测试编写程序时，我才终于开始明白一般。测试不应导致愚蠢的体系结构。并非如此，复制和粘贴20个文件，然后仅对其中两个进行重大更改，没有什么比它更具可伸缩性或企业价值了。这个想法是要分离关注点，而不是将它们分解到中间。毫无用处和毫无意义的抽象将使您付出95％的覆盖率。

• 它真的很受欢迎，很多人真的非常喜欢它。如果在采用之前没有足够的理由至少进行第二次猜测和/或审查任何技术，请了解一些偏执狂。