说服开发人员学习TDD的最佳理由是什么？

Question

让我先走出壁橱。我是TDD的信徒。我正尽力练习测试驱动开发。

我工作的一些开发人员甚至拒绝尝试。我自己开始TDD试图向我的同行证明测试驱动开发是一个坏主意。论点是：

• 为什么？到目前为止，我是非常成功的开发人员。
• 这会让我慢下来。

最好的专业TDD论证听到或使用过什么？

---

另请参阅： What is the best reason for unit testing?

Answer 1

也许他们知道的更好。

开发人员

单元测试是一个非常有用的实践，我不能过分强调它的好处，不仅在初始开发期间，而且在重构期间，单元测试不仅能够及早发现普通的代码缺陷而且还能在开发人员做出的假设从未在正式文档中捕获，因此可能在重构发生时丢失。

话虽如此，TDD并不是神奇的小精灵：

1. '只需编写足够的代码来通过测试'方法会产生误报。通常存在已知的谬论和问题，即“恰到好处”的方法无法解决。想到的快速示例是distributed systems fallacies或NUMA性能问题。只需将这些需求捕获到表达 TDD的那些测试用例中，就会变成一份全职工作。
2. 对于任何规模较大的项目，moqs的爆炸都会失控。模拟代码就像任何其他代码一样，它们需要维护，只是不要自己写出来。
3. TDD通常被用作消除QA测试的借口。 '我们的开发人员已经编写了经过测试的id，让它发货'完全忽略端到端功能导向测试QA应该涵盖
4. 我不相信守卫鸡舍的狐狸。如果在测试和实现中都出现相同的错误，错误的算法仍然可以通过TDD传递颜色。
5. 最终所有方法都试图用流程代替人才。

我与TDD的主要争议是作为解决大多数发展问题的神奇解决方案，但其成本由其拥护者保留在桌面之下。使用moqs将代码库加倍或增加三倍并不是免费的。我更愿意在开发过程中看到一些全面的单元测试。测试优先的TDD方法，我还没有看到它在实际规模项目中的好处。

我知道我现在因为张贴这个而被杀死了，但到底是什么，谁在乎......

Answer 2

任何争论都不会说服任何人使用TDD。

你必须展示它们，并展示它们的好处。通过表现而不是说出来，让某些人的光变得更容易。

Answer 3

TDD是“现在付钱给我还是以后付钱”的权衡。如果您只计算从开始编码到检查代码的时间，那么TDD通常需要更长的时间，尤其是在首次学习TDD时。在测试阶段以及未来的编码轮次中都会得到回报。

在测试阶段，我发现使用TDD：

1. 我的错误要少得多。我的最后一个TDD代码我的错误只是由于需求误解（或更改）或我无法测试代码的区域（在这种情况下是PHP代码）。
2. 我所遇到的错误通常更容易在测试中重现，因为我已经让系统受到了测试。
3. 修复错误的速度更快，通过测试我可以更加相信我没有引入新的错误。

代码本身具有以下属性：

1. 当我开始像代码的客户端一样思考时，代码往往更容易使用。 （这是首先编写测试的好处之一）。

2. 代码更容易测试。

3. 编写单元测试比以前更容易（在许多情况下更有趣），因此会编写更多测试。

4. 代码更容易重构和清理。对于Python来说尤其如此，其中自动重构工具的难度更大。

因此，当重新访问代码时，它更容易理解并且更容易更改，而且我们至少已经进行了一些回归测试。

这意味着TDD时间的回报可能月。此外，使用遗留代码启动TDD尤其困难。然后有时间学习如何编写好的测试（一个糟糕的测试集可能不够或者更糟糕的是使得更难，更容易做重构）以及如何使一个复杂的系统受到测试。

我不得不承认，我真的无法让其他人太多转而使用TDD。我认为我的转变主要是因为我想要一种更简单的测试方式，而且我还有机会学习如何使用小代码库和个人项目。

Answer 4

不同的人会以不同的方式相信（或不相信），所以唯一诚实的答案是“它取决于”。

我多次看到工作的一种方法是在他们努力处理大量代码后与某人坐在一起，并使用TDD重新创建它。生成的代码通常更小，更清晰。

Answer 5

我不练习TDD。虽然我看到如果您有复杂的项目，并且您有许多不同的测试用例需要测试，但是我认为这样做很好，但我认为在一个简单的Web应用程序中使用它并没有什么好处。

有人可以说服我使用TDD的一种方式是，如果我们采用相同的项目并将它们并排进行，看看谁能提供更好的结果，谁能更快地完成任务。

Answer 6

与他们配对。你不必把它称为“结对编程” - 这对那些不愿意考虑像TDD这样的“激进”技术的人来说是可怕的 - 但是如果你们两个坐在办公桌前就同一个问题一起工作，那就很容易了证明了TDD的价值。这不可能是谈话的结束，但这是一个开始的地狱。使您在剩下的对话中具有可信度，并为您提供真实的东西作为进一步讨论的基础。

Answer 7

对我而言，“aha”时刻正在阅读James Newkirk撰写的“Microsoft.Net中的测试驱动开发”第2章。 （并不是说本书的其余部分并不重要......他将几章用于在TDD中构建多层应用程序。）

他构建了一个简单的堆栈，但是你可以看到代码“发展”它的复杂性，而不是开始复杂。

即便如此，你仍然无法说服那些说话者，因为看起来TDD需要比传统节目更多的工作。然而，大多数反TDD开发人员忘记了在最后进行单元测试的开发时间，至少根据我的经验。

Answer 8

您列出的参数不是合理的逻辑参数。他们没有理由支持他们（除非你实际上只是总结了更长的真实论点。）

因此，我认为你不能说服那些以你自己的理性论据提出这些主张的人。最好的方法是诉诸他们的论据来源;经验。要么让他们在临时基础上使用TDD一段时间来看看他们对它的看法，要么自己做TDD工作，这显然是非常好的工作，并以此为例向他们展示。

（我不是TDD的信徒。这是一种实用的方式，你可以说服我这是一个好主意。）

Answer 9

作为一名10年以上的专业开发人员，我能提出的最好的论据是，即使我在实际能够“运行”应用程序之前发现了我的错误。

我还发现我的代码设计更强大，更容易更改，这让我对重构更有信心。

“非常成功”并不等于“真正成功”。

另一个很大的优势是我不再需要编写测试装备，因为单元测试跑步者有效地成为了我的测试工具。

Answer 10

向他们展示此演示文稿。它卖给了我。

http://www.slideshare.net/sebastian_bergmann/testing-with-phpunit-and-selenium-156187

任何曾经遇到过具有大量边缘条件的复杂任务的程序员都应该能够看到TDD的价值。当谈到确保搜索引擎匹配某些字符串时，TDD是您在维护期间能够保持理智的唯一方法 - 确保您修复一个案例而不破坏其他一些案例的唯一方法是自动化测试。

Answer 11

彻底的单元测试可以减少错误的发生，但它们也会减少因重新生成而造成的再生或损坏范围。