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

TDD是一种“现在付钱还是以后付钱”的权衡。如果只计算从开始编码到检入代码的时间,那么TDD通常会花费更长的时间,特别是在第一次学习TDD时。在测试阶段的稍后阶段,以及在未来的几轮编码中,都会得到回报。

在测试阶段,我发现使用TDD:

1. 我几乎没有虫子。我的上一个TDD代码只有在需求误解(或者变更)或者在我无法将代码进行测试的领域(在这种情况下是PHP代码)才会有缺陷。
2. 在测试中,我所拥有的bug通常更容易复制,因为我已经对系统进行了测试。
3. 修复bug的速度更快,通过测试,我更相信自己没有引入新的bug。

代码本身具有以下属性:

1. 当我开始像代码的客户机一样思考时,代码往往更容易使用。(这是先写测试的好处之一)。

2. 代码更容易测试。

3. 在单元测试之前而不是之后编写单元测试更容易(而且在许多情况下更有趣),因此编写了更多的测试。

4. 代码更容易重构和清理。在Python中尤其如此,因为自动重构工具很难实现。

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

这意味着TDD时间的回报可能是 月 后来。此外,用遗留代码启动TDD特别困难。然后,我们需要时间来学习如何编写好的测试(坏的测试集要么不够,要么更脆弱,从而使重构变得更困难,而不是更容易),以及如何让一个复杂的系统接受测试。

我不得不承认,我真的没办法让太多的人转而使用TDD。我想我之所以改变主要是因为我想要一种更简单的测试方法,而且我有机会学习如何使用一个小的代码库和个人项目。

也许他们更清楚。

单元测试 开发人员是一个非常有用的实践,我不能过分强调它的好处,不仅在初始开发期间,而且在重构期间,单元测试不仅可以早期捕获普通的代码缺陷,而且还可以破坏开发人员在正式文档中从未捕获到的假设,因此可能会被T所丢失。IME重构发生。

这就是说,TDD不是神奇的精灵尘:

1. “只需编写足够的代码来通过测试”方法会产生误报。通常有一些已知的谬误和问题,“刚好”的方法无法解决。想到的快速例子是 distributed systems fallacies 或numa性能问题。只需简单地将这些需求 表达 TDD的这些测试用例本身就会变成一个全职工作。
2. 对于任何规模大的项目来说,能源部的爆炸都失去了控制。模拟和其他任何代码一样,都是代码,它们需要维护,只是不要突然写出来。
3. TDD通常被用作消除质量保证测试的借口。我们的开发人员已经编写了测试ID,让我们发布它完全忽略了面向端到端特性的测试QA应该涵盖的内容。
4. 我不相信狐狸看守鸡舍。一 错误的 如果在测试和实现中都出现了相同的错误,算法仍然可以通过彩色TDD。
5. 最终所有的方法都试图用过程来替代人才。

我与TDD的主要争论是,它被认为是解决大多数开发问题的一个神奇的方法,但它的成本却被它的倡导者们压在了桌子下面。使用moq将代码库翻倍或翻倍并不是免费的。我更愿意看到在开发期间编写的一些全面的单元测试。首先测试TDD方法,我还没有看到它在实际规模项目中的好处。

我知道我现在会因为发布这个而被判死刑,但那该死的,谁在乎呢…

再多的争论也不能说服任何人使用TDD。

你必须展示它们,并展示它们的好处。通过展示而不是诉说,更容易让人“轻装上阵”。

不同的人会以不同的方式被说服(或不被说服),所以唯一诚实的答案是“这取决于”。

我见过很多次的工作,其中一种方法就是在一段代码遇到困难后,和某人坐在一起,然后使用TDD重新创建它。生成的代码通常更小、更清晰。

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

有人能说服我使用TDD的一种方法是,如果我们采用相同的项目并并排进行,看看谁能得出更好的结果,谁能更快地完成任务。

与他们配对。你不必称之为“结对编程”,这对那些不愿意考虑像TDD这样的“激进”技术的人来说是很可怕的,但是如果你们两个坐在一张桌子上一起解决同一个问题,就很容易证明TDD的价值。这不是谈话的结束,但这是一个地狱般的开始。在接下来的谈话中给你可信度,并给你一些真实的东西作为进一步讨论的基础。

对我来说,“啊哈”的时刻是读詹姆斯·纽柯克的《微软.NET测试驱动开发》第二章。(这本书的其余部分并不重要……他为在TDD中构建多层应用程序专门写了几章)。

他构建了一个简单的堆栈,但您可以看到代码“进化”其复杂性,而不是从复杂开始。

即便如此,您仍然很难说服反对者,因为看起来TDD需要比传统编程更多的工作。然而,大多数反TDD开发人员在最后忘记考虑单元测试的开发时间,至少在我的经验中是这样。

您列出的参数不是理性的逻辑参数。他们背后没有理由(除非你已经总结了更多的真实论点。)

因此,我不认为你能说服任何用你自己的理性论据提出这些主张的人。最好的方法是诉诸他们论点的来源;经验。要么让他们暂时使用TDD,看看他们怎么想,要么让他们自己做TDD工作,这显然是非常好的工作,并作为一个例子展示给他们。

(我不是TDD的信徒。这是一个实用的方法,你可以让我相信这是个好主意。)

作为一个10多年的专业开发人员,我能提出的最好的论点是,在我真正能够“运行”应用程序之前,我甚至发现了我的bug。

我还发现我的代码的设计更健壮,更容易更改,这让我对重构更有信心。

“相当成功”并不等于“真正成功”。

另一个好处是,当单元测试运行人员有效地成为我的测试工具时,我不再需要编写测试工具。

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

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

任何一个曾经面对一个非常复杂的任务和很多边缘条件的程序员都应该能够看到TDD的价值。当涉及到诸如确保搜索引擎匹配某些字符串之类的问题时,TDD是您在维护期间能够保持清醒的唯一方法——确保在不破坏其他一些情况下修复一个案例的唯一方法是使用自动测试。

彻底的单元测试减少了错误的发生,但是它们也减少了重复划分或由重复划分引起的损坏范围。