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

Question

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

1. 您使用哪些项目使用测试驱动的开发？您是否仅将其用于一定规模的项目？
2. 我应该使用它吗？说服我！

Answer 1

好的，TDD的一些优势：

1. 这意味着您最终会进行更多测试。每个人都喜欢 有 测试，但很少有人喜欢 写作 他们。在开发流程中构建测试编写意味着您最终会进行更多测试。
2. 写信给测试迫使您考虑设计的可检验性，可测试的设计是 几乎 总是更好的设计。我并不完全清楚为什么情况如此，但是我的经验和大多数TDD福音传教士的经验似乎都忍受了。
3. 这是一项研究 说，尽管TDD需要更长的时间来写作，但由于您获得了更高质量的代码，因此可以修复的错误，但可以进行良好的投资回报。
4. 它使您有信心重构。能够更改一个系统而又不必担心破坏其他所有操作，这是一种很棒的感觉，因为它在单位测试中得到了很好的覆盖。
5. 您几乎永远不会得到重复错误，因为您发现的每个人都应该在修复程序之前进行测试。

您要求说服，所以这是好处。看 这个问题 为了获得更平衡的视图。

Answer 2

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

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

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

Answer 3

（免责声明：我几乎没有任何UI的内容，所以我无法为UI讨论TDD。）

从微不足道的应用到整个SIP堆栈，我几乎都会在几乎所有工作中使用TDD。

我不在我接管的Legacy PHP网站中使用TDD。我发现没有测试很痛苦。而且我发现这非常令人讨厌，因为我没有回归测试套件告诉我我打破了一些东西，因此意外地破坏了网站的一部分。客户没有为我提供预算（a）为代码库编写测试，并且（b）在此过程中首先可以测试代码，因此我只是忍受了。

Answer 4

• 只要您的客户可以更有效地提供（它们可能与测试都有很好的关系 - 并且至少会减少项目终结讨论）
• 只要您要使您的共同开发人员通知代码中的所有人都需要更长的时间来构建测试，那么这比您想象的要早得多

Answer 5

什么？没有负面答案！？

免责声明：我不是反单位测试。当人们说TDD时，我认为他们是指在编写所有代码的80-100％之前编写代码之前编写测试的版本。

我会争辩：

• 这是一个推动者。如果捕捉回归问题对您来说是一个巨大的问题，那么从一开始就值得全自动TDD，为您编写的每篇代码编写测试，实际上可能会帮助您忽略真正的问题。

• 它可以帮助人们忽略真正的问题。当修复一个错误时，变成了一个whack-a-mole的游戏，其中又有两个弹出窗口时，体系结构会打击。重点。专注于真正的问题。在必须鞭打的痣之前，看到它们是整洁的O，但您首先不应该在那里。

• 它吃了很多时间。我偶尔遇到错误。我没有击中太多，以至于我写的每件新东西都值得一提。抓住它们可能发生的问题。处理错误，使其易于诊断。证实。在重叠/瓶颈的关键点进行测试。但是，要大声喊叫，请不要测试所有最后的固定器，而这可能首先不应该拥有的东西。

• 设计焦点：即使是一个好的开发人员也绝对没有办法编写他们还专注于测试的最佳代码。如果您似乎是唯一可以实现不错的设计的方法，我建议您看到以上有关“专注于真正问题”的内容。

• 宏设计失败：我目前工作的代码库带有从未使用过的界面，这些界面从未使用过不止一次，并且对基本的干燥原则的严重违规行为，当我意识到人们正在为测试框架和测试写作时，我才最终开始理解一般的。测试不应导致愚蠢的体系结构。不，真的，没有什么比复制和粘贴20个文件更可扩展或企业更具可扩展性或企业的作用。这个想法是要分开关注，而不是将它们分开。克鲁夫特（Cruft）和毫无意义的抽象将花费您的95％的覆盖范围。

• 它真的很受欢迎，很多人真的非常喜欢它。如果这还不足以至少在采用之前的任何技术中至少猜测和/或审查废话，请学习一些偏执狂。