我在其他任何答案中都没有看到这一点，但我注意到的一件事是，我可以更快地调试。你不需要通过正确的步骤序列深入到你的应用程序中，只发现你犯了一个布尔错误，需要重新做一遍。使用单元测试，您可以直接进入正在调试的代码。

当您手动测试软件时，通常会使用一小组测试/操作。最终，您将自动修改输入数据或操作，以便围绕已知问题进行导航。应该有单元测试来提醒您某些事情不能正常工作。

我建议在编写代码之前编写测试，添加新的测试/数据来改进主代码的功能!

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

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

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

@George Stocker“不幸的是，我们的代码库并不适合简单的测试。”每个人都同意单元测试有好处，但对于这个代码库来说，成本似乎很高。如果成本大于收益，那么他们为什么要对此充满热情呢?倾听你同事的意见;也许对他们来说，单元测试的痛苦比单元测试的价值更大。

具体地说，尽量尽快获得价值，而不是一些感觉良好的“xUnit是绿色的”价值，而是用户和维护者所重视的干净代码。也许您必须为一次迭代强制进行单元测试，然后讨论是否值得这样做。

单元测试的全部意义在于使测试变得简单。这是自动的。“make test”就完成了。如果您面临的问题之一是难以测试代码，那么这就是使用单元测试的最佳理由。

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