我不知道。很多地方不做单元测试，但是代码质量很好。微软做单元测试，但是比尔·盖茨在他的演示中出现了蓝屏。

最好的说服方式是……找到一个bug，为它写一个单元测试，修复这个bug。

这个特定的错误不太可能再次出现，您可以通过测试来证明它。

如果你做得足够多，其他人很快就会明白。

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

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

就在今天，我不得不更改一个类，之前已经为其编写了单元测试。 测试本身写得很好，包括我甚至没有想过的测试场景。 幸运的是，所有测试都通过了，我的更改很快得到了验证，并自信地放到了测试环境中。

关于这个话题，我写了一篇很大的博客文章。我发现单靠单元测试是不值得的，而且通常在截止日期临近时就会被削减。

与其从“测试后验证”的角度来讨论单元测试，我们应该看看在实现之前编写规范/测试/想法时所发现的真正价值。

这个简单的想法改变了我写软件的方式，我不会回到“旧的”方式。

测试优先开发如何改变了我的生活

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