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

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

作为一名物理专业的学生，我非常有动力去证明我的代码是可以正常工作的。您可以从逻辑上证明这一点，随着实现变得更加复杂，难度会急剧增加，或者您可以通过良好的测试对功能进行(尽可能接近的)经验证明。

如果不提供函数的逻辑证明，就必须进行测试。唯一的选择是说“我认为代码可以工作....”

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

我最近在我的工作场所经历了完全相同的经历，发现大多数人都知道理论上的好处，但必须具体地向他们推销这些好处，所以下面是我使用的(成功地)要点:

它们在执行负测试(处理意外输入(空指针、越界值等)时节省了时间，因为您可以在单个进程中完成所有这些。 它们在编译时提供关于更改标准的即时反馈。 它们对于测试在正常运行时可能不会公开的内部数据表示非常有用。

还有那个大的…

您可能不需要单元测试，但是当其他人进入并在没有完全理解的情况下修改代码时，它可以捕捉到他们可能犯的许多愚蠢的错误。

如果你正在使用NUnit，一个简单而有效的演示就是在他们面前运行NUnit自己的测试套件。看到一个真正的测试套件对代码库进行测试，胜过千言万语……

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

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

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