根据我的经验，在复杂的软件环境中，单元测试和集成测试是“必须的”。

为了说服团队中的开发人员编写单元测试，您可能需要考虑在开发环境中集成单元测试回归分析(例如，在您的日常构建过程中)。

一旦开发人员知道如果单元测试失败，他们就不必花那么多时间调试它来发现问题，他们就会更有动力去编写这些测试。

这里有一个工具可以提供这样的功能:

单元测试回归分析工具

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

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

单元测试非常值得最初的投资。自从几年前开始使用单元测试以来，我发现了一些真正的好处:

回归测试消除了恐惧 对代码进行更改(什么都没有 就像看到代码的温暖光芒 每次有变化，要么工作，要么爆发 了) 以下的可执行代码示例 其他团队成员(包括你自己) 6个月的时间…) 无情的重构——这是令人难以置信的回报，试试吧!

代码片段可以极大地帮助减少创建测试的开销。创建能够在几秒钟内创建类大纲和相关单元测试fixture的代码片段并不困难。

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

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

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

你应该尽量少测试!

这意味着，您应该编写足够多的单元测试来揭示意图。这一点经常被掩盖。单元测试的成本很高。如果您进行了更改，并且必须更改测试，那么您将不那么敏捷。保持单元测试短小精悍。这样它们就有很大的价值。

我经常看到许多永远不会崩溃的测试，它们又大又笨拙，没有提供太多价值，它们最终只会拖慢你的速度。

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

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