我如何说服团队中的程序员做TDD？

Question

我知道这个问题：https://stackoverflow.com/questions/428691/how-to-encourage-implementation-of-tdd

在我的团队中，我们编写了很多单元测试。但是，通常程序员倾向于在编写代码之后编写单元测试。因此，我们首先完成模块功能，然后编写测试。大多数模块的覆盖率约为70％。我已经尝试说服我的技术经理和我的团队成员做纯TDD，其中我们首先编写测试然后编写代码，但是重新获得。我认为首先编写测试可以让我们更好地发现设计。我只是挑剔，特别是当我们的报道很高时？如果这个问题的答案是否定的，那么我该如何与人们谈论采用测试优先的方法。

编辑：我认为编写代码后编写测试更容易。我团队中的人已习惯这样做，反对任何改变。

Answer 1

我不知道有很多你可以告诉让他们相信TDD的价值。您可以引用专家告诉我们的内容以及您自己的个人经历，但是如果人们不愿意尝试一下，那么与他们分享这些信息的机会很低。

我对TDD的体验基本上听起来像是一个非常好的主意，但它从来没有按照预期的方式实现。然后有一天，我再次尝试了一项新任务，最终找到了一个比我想象的更简单的问题解决方案，完全归功于我使用过TDD这一事实。我认为，当开发人员拥有这种体验时，它会改变他们看待事物的方式，并使他们更愿意在其他情况下尝试它。

挑战是能够向其他开发者证明这一点。你可以做到这一点的一种方法是使用来自Roy Osherove的this one的TDD卡塔（他在他的TDD硕士课程中使用它）。它专门用于演示以小步骤工作的价值，仅实现使每个测试通过所需的代码。这可能会向人们展示这个过程是如何运作的，并让他们尝试更舒服。

我还听说过一个编码练习，你给了两个团队/开发团队一个相当简单的任务，并要求其中一个团队使用TDD，并确保他们遵循“最简单的可能工作”规则，而另一个团队做了他们想要的事情。然后，一旦完成，您就可以让团队切换任务，但是抛弃每个团队编写的代码，只留下测试。然后团队应该重新创建任务的代码。通常，您会发现继承TDD代码的团队可以更轻松地完成此任务。

尽管如此，我认为你可以做的最好的事情就是尽可能多地开始做TDD。这有可能为您提供一些非常具体的参考资料，说明在当前项目的背景下TDD在何处以及如何被证明是有益的。特别是如果您进行代码审查，您的同行可能会注意到您编写的代码TDD比没有TDD编写的代码更简洁，更易于维护。您的QA团队也可能会注意到代码质量的差异，这是您听到很多关于迁移到TDD的公司的事情之一。

Answer 2

一些建议。您的实用性可能会有所不同：

• 赢得一两个人：你的老板，实习生等，先到你身边。您的first follower会让您成为领导者。
• 开始配对编程或指导。即使它只是一个实习生或两个人，与某人密切合作可能是影响他们风格的好方法。如果你愿意，你可以尝试成为一名经理。
• 就此主题进行技术演示。重点关注您解决的原因和问题，而不是TDD。您希望人们购买问题而不是您的具体解决方案。包括其他一些替代方案，因此您似乎并没有尝试推动适合您的方案。
• 从Object Mentor等获得一些外部培训。如果你可以说服你的老板并且团队不是一群硬化的没有灵魂的愤世嫉俗者，那就最好了。

Answer 3

老实说，你应该总是使用一个有效的开发/测试周期。

许多人喜欢TDD，很多像谷歌这样的大玩家已经接受了它;因为测试覆盖率很高。

然而，似乎你和你的团队在没有它的情况下往往做得很好 - 并且记住，改变开发风格至少会暂时降低生产力。所以请记住古老的谚语，不要改变有效的方法。

然而，如果您和您的客户发现测试中仍然存在大量错误，那么TDD是理想的方法 - 所以您应该告诉管理层TDD是一种提高客户满意度的方式，从而赚钱。 （那是管理层 - 为你说话！）

Answer 4

也许以身作则可以提供帮助：

自己开始这样工作

也许创建一个tutorial \ script来设置不会给TDD进程增加开销的环境（IDE）：

1. 使用单个键盘快捷键运行测试
2. 测试系统的GUI应该出现在开发视图中（不仅仅是在测试视图中，因此您不必在它们之间移动）

我猜测过了一段时间后，人们会好奇并问你这个TDD这个东西是否真的有效，你应该为这个问题准备好答案： - ）

Answer 5

你有没遇到过BDD？有一个相关的词汇变化我发现真的有助于TDD的新人捡起它。这是词汇变化：

http://lizkeogh.com/2009/11/06/translating-tdd-to-bdd/

我发现使用这种语言有助于人们关注为什么首先编写测试（或示例）是有用的。我在评论中翻译了另一个例子。

即便如此，有时候了解测试的结构也很有帮助。如果人们在学习如何首先编写它们时遇到困难，那么之后编写它们是一个很好的学习步骤。你对设计的好处是正确的。可能需要一段时间才能理解。

在过去，我发现获得TDD的最佳方式是拥有一个安全的练习环境。拥有自己的玩具应用程序或基于玩具应用程序的运行/参加研讨会都对我有很大的帮助。 / p>