我知道这个问题：https://stackoverflow.com/questions/428691/how-to-encourage-implementation-of-tdd
在我的团队中，我们编写了很多单元测试。但是，通常程序员倾向于在编写代码之后编写单元测试。因此，我们首先完成模块功能，然后编写测试。大多数模块的覆盖率约为70％。我已经尝试说服我的技术经理和我的团队成员做纯TDD，其中我们首先编写测试然后编写代码，但是重新获得。我认为首先编写测试可以让我们更好地发现设计。我只是挑剔，特别是当我们的报道很高时？如果这个问题的答案是否定的，那么我该如何与人们谈论采用测试优先的方法。
编辑：我认为编写代码后编写测试更容易。我团队中的人已习惯这样做，反对任何改变。
答案 0 :(得分：17)
我不知道有很多你可以告诉让他们相信TDD的价值。您可以引用专家告诉我们的内容以及您自己的个人经历，但是如果人们不愿意尝试一下，那么与他们分享这些信息的机会很低。
我对TDD的体验基本上听起来像是一个非常好的主意，但它从来没有按照预期的方式实现。然后有一天，我再次尝试了一项新任务，最终找到了一个比我想象的更简单的问题解决方案，完全归功于我使用过TDD这一事实。我认为，当开发人员拥有这种体验时，它会改变他们看待事物的方式，并使他们更愿意在其他情况下尝试它。
挑战是能够向其他开发者证明这一点。你可以做到这一点的一种方法是使用来自Roy Osherove的this one的TDD卡塔（他在他的TDD硕士课程中使用它）。它专门用于演示以小步骤工作的价值，仅实现使每个测试通过所需的代码。这可能会向人们展示这个过程是如何运作的，并让他们尝试更舒服。
我还听说过一个编码练习，你给了两个团队/开发团队一个相当简单的任务，并要求其中一个团队使用TDD，并确保他们遵循“最简单的可能工作”规则，而另一个团队做了他们想要的事情。然后，一旦完成，您就可以让团队切换任务，但是抛弃每个团队编写的代码，只留下测试。然后团队应该重新创建任务的代码。通常，您会发现继承TDD代码的团队可以更轻松地完成此任务。
尽管如此，我认为你可以做的最好的事情就是尽可能多地开始做TDD。这有可能为您提供一些非常具体的参考资料，说明在当前项目的背景下TDD在何处以及如何被证明是有益的。特别是如果您进行代码审查，您的同行可能会注意到您编写的代码TDD比没有TDD编写的代码更简洁，更易于维护。您的QA团队也可能会注意到代码质量的差异，这是您听到很多关于迁移到TDD的公司的事情之一。
答案 1 :(得分：9)
一些建议。您的实用性可能会有所不同：
答案 2 :(得分：4)
老实说，你应该总是使用一个有效的开发/测试周期。
许多人喜欢TDD，很多像谷歌这样的大玩家已经接受了它;因为测试覆盖率很高。
然而，似乎你和你的团队在没有它的情况下往往做得很好 - 并且记住，改变开发风格至少会暂时降低生产力。所以请记住古老的谚语，不要改变有效的方法。
然而，如果您和您的客户发现测试中仍然存在大量错误，那么TDD是理想的方法 - 所以您应该告诉管理层TDD是一种提高客户满意度的方式，从而赚钱。 （那是管理层 - 为你说话！）
答案 3 :(得分：4)
也许以身作则可以提供帮助：
自己开始这样工作
也许创建一个tutorial \ script来设置不会给TDD进程增加开销的环境（IDE）：
我猜测过了一段时间后，人们会好奇并问你这个TDD这个东西是否真的有效，你应该为这个问题准备好答案： - ）
答案 4 :(得分：1)
你有没遇到过BDD？有一个相关的词汇变化我发现真的有助于TDD的新人捡起它。这是词汇变化：
http://lizkeogh.com/2009/11/06/translating-tdd-to-bdd/
我发现使用这种语言有助于人们关注为什么首先编写测试（或示例）是有用的。我在评论中翻译了另一个例子。
即便如此，有时候了解测试的结构也很有帮助。如果人们在学习如何首先编写它们时遇到困难，那么之后编写它们是一个很好的学习步骤。你对设计的好处是正确的。可能需要一段时间才能理解。
在过去，我发现获得TDD的最佳方式是拥有一个安全的练习环境。拥有自己的玩具应用程序或基于玩具应用程序的运行/参加研讨会都对我有很大的帮助。 / p>