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

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

[我有一个观点，我不能在上面看到]

“每个人都在进行单元测试，他们不一定意识到这一点——事实”

想想看，你写了一个函数来解析一个字符串并删除新的行字符。作为一个开发新手，你要么在命令行中通过Main()实现它来运行几个用例，要么用一个按钮组合一个可视化前端，将你的函数绑定到几个文本框和一个按钮上，然后看看会发生什么。

这就是单元测试——基本的和糟糕的组合在一起，但是你测试了一些情况下的代码段。

你写一些更复杂的东西。当您抛出一些用例(单元测试)并将其调试到代码中并进行跟踪时，它会抛出错误。你在浏览过程中查看这些值，并决定它们是对还是错。在某种程度上，这是单元测试。

这里的单元测试实际上是采用这种行为，将其形式化为结构化模式并保存，以便您可以轻松地重新运行这些测试。如果您编写了一个“适当的”单元测试用例而不是手动测试，那么它所花费的时间是相同的，或者随着您的经验的增加可能会更少，并且您可以一次又一次地重复它

Yes - Unit Testing is definitely worth the effort but you should know it's not a silver bullet. Unit Testing is work and you will have to work to keep the test updated and relevant as code changes but the value offered is worth the effort you have to put in. The ability to refactor with impunity is a huge benefit as you can always validate functionality by running your tests after any change code. The trick is to not get too hung up on exactly the unit-of-work you're testing or how you are scaffolding test requirements and when a unit-test is really a functional test, etc. People will argue about this stuff for hours on end and the reality is that any testing you do as your write code is better than not doing it. The other axiom is about quality and not quantity - I have seen code-bases with 1000's of test that are essentially meaningless as the rest don't really test anything useful or anything domain specific like business rules, etc of the particular domain. I've also seen codebases with 30% code coverage but the tests were relevant, meaningful and really awesome as they tested the core functionality of the code it was written for and expressed how the code should be used.

在探索新的框架或代码库时，我最喜欢的一个技巧是为“它”编写单元测试，以发现事物是如何工作的。这是一个学习新事物的好方法，而不是阅读枯燥的文档:)

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

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

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

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

还有那个大的…

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

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

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