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

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

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

我同意与大多数人相反的观点: 不编写单元测试是可以的 特别是重原型的编程(例如AI)很难与单元测试相结合。

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

当涉及到重构或重写一段代码时，单元测试也特别有用。如果您有良好的单元测试覆盖率，您就可以满怀信心地进行重构。如果没有单元测试，通常很难确保您没有破坏任何东西。

让你测试的第一个东西与单元测试无关。我主要使用Perl工作，所以这些都是特定于Perl的示例，但您也可以适应。

每个模块是否正确加载和编译?在Perl中，这是一个创建Foo的问题。t对每个Foo。PM的代码库，它做: use_ok('Foo'); 所有的POD(普通文档)格式是否正确?使用Test::Pod来验证所有文件中所有Pod格式的有效性。

你可能不认为这些是大事情，他们不是，但我可以保证你会抓到一些泔水。当这些测试每小时运行一次，并捕捉到某人的过早提交时，您会让人们说“嘿，这很酷”。

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

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