单元测试的一个好处是，它们可以作为说明代码行为方式的文档。好的测试有点像参考实现，团队成员可以通过查看它们来了解如何将他们的代码与您的代码集成。

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

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

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

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

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

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

Unit Testing is one of the most adopted methodologies for high quality code. Its contribution to a more stable, independent and documented code is well proven . Unit test code is considered and handled as an a integral part of your repository, and as such requires development and maintenance. However, developers often encounter a situation where the resources invested in unit tests where not as fruitful as one would expect. In an ideal world every method we code will have a series of tests covering it’s code and validating it’s correctness. However, usually due to time limitations we either skip some tests or write poor quality ones. In such reality, while keeping in mind the amount of resources invested in unit testing development and maintenance, one must ask himself, given the available time, which code deserve testing the most? And from the existing tests, which tests are actually worth keeping and maintaining? See here

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

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

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

你应该尽量少测试!

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

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