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

Question

让我先走出壁橱.我是TDD的信徒.我正在尝试尽可能多地练习测试驱动开发.

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

• 为什么？到目前为止,我是非常成功的开发者
• 这会让我慢下来.

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

---

另请参阅: 单元测试的最佳原因是什么？

Answer 1

也许他们知道的更好.

开发人员的单元测试是一个非常有用的实践,我不能过分强调它的好处,不仅在初始开发期间,而且在重构期间,单元测试不仅可以及早发现普通的代码缺陷,而且可以突破开发人员所做的假设,而这些假设从未在正式文档因此很可能在重构发生时丢失.

话虽这么说,TDD不是神奇的小精灵尘埃:

1. '只需编写足够的代码来通过测试'方法会产生误报.通常存在已知的谬论和问题,即"恰到好处"的方法无法解决.想到的快速示例是分布式系统谬误或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.我认为我的转换很大程度上是因为我想要一种更简单的测试方式,而且我还有机会学习如何使用小代码库和个人项目.