还没有人提到的一件事是，让所有开发人员承诺实际运行和更新任何现有的自动化测试。当您重新进行自动化测试并发现由于新的开发而出现故障时，会失去很多价值并使自动化测试非常痛苦。因为开发人员已经手动测试了代码，所以大多数测试不会指出错误，所以花在更新它们上的时间只是浪费。

说服怀疑者不要破坏其他人在单元测试上所做的工作，对于从测试中获得价值更为重要，而且可能更容易。

每次从存储库更新时，花费数小时更新由于新特性而损坏的测试既没有效率也没有乐趣。

单元测试适用于QA人员或你的经理，而不是你;所以绝对不值得。

您应该专注于编写正确的代码(不管这意味着什么)，而不是测试用例。让其他人去担心吧。

我在几年前发现了TDD，从那时起我就使用它编写了所有我喜欢的项目。我估计，TDD一个项目所花费的时间与牛仔式地组合一个项目所花费的时间大致相同，但我对最终产品的信心增加了，以至于我忍不住有一种成就感。

我还觉得它改进了我的设计风格(更面向界面，以防我需要一起模拟东西)，而且，正如顶部的绿色帖子所写的，它有助于“编码便秘”:当你不知道接下来要写什么，或者你有一个令人生畏的任务摆在你面前时，你可以写小一点的。

最后，我发现到目前为止，TDD最有用的应用是在调试中，如果仅仅因为您已经开发了一个询问框架，那么您就可以用它来刺激项目以可重复的方式产生错误。

你想说服谁?工程师还是经理?如果你试图说服你的工程师同事，我认为你最好的办法是迎合他们的愿望，让他们做出高质量的软件。有许多研究表明，它能发现漏洞，如果他们关心做好工作，这对他们来说就足够了。

如果您试图说服管理层，您将很可能不得不做一些成本/收益推理，说明未检测到的缺陷的成本大于编写测试的成本。一定要把不可转化的成本也包括在内，比如失去客户的信心等等。

这是非常以. net为中心的，但是有人尝试过Pex吗?

我非常怀疑，直到我尝试了——哇，多么精彩的表演。以前我想“我不会被这个概念说服，直到我明白它实际上对我有什么好处”。我只跑了一次就改变了主意，说:“我不在乎你怎么知道那里有致命异常的风险，但现在我知道我必须处理它”

也许这种行为唯一的缺点是它会标记所有事情，给你六个月的积压。但是，如果你有代码债，你总是有代码债，只是你不知道而已。告诉项目经理可能有20万个故障点，而你之前只知道有几十个，这是一个令人讨厌的前景，这意味着首先解释这个概念是至关重要的。

测试驱动开发中经常被忽略的一个主要部分是可测试代码的编写。乍一看，这似乎是一种妥协，但您会发现可测试代码最终也是模块化的、可维护的和可读的。 如果你仍然需要说服别人，这是一个关于单元测试优点的简单演示。