使用单元测试套件，可以在保持其余功能不变的情况下对代码进行更改。这是一个很大的优势。当你完成新功能的编码时，你会使用单元测试套件和回归测试套件吗?

还没有人提到的一件事是，让所有开发人员承诺实际运行和更新任何现有的自动化测试。当您重新进行自动化测试并发现由于新的开发而出现故障时，会失去很多价值并使自动化测试非常痛苦。因为开发人员已经手动测试了代码，所以大多数测试不会指出错误，所以花在更新它们上的时间只是浪费。

说服怀疑者不要破坏其他人在单元测试上所做的工作，对于从测试中获得价值更为重要，而且可能更容易。

每次从存储库更新时，花费数小时更新由于新特性而损坏的测试既没有效率也没有乐趣。

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

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

当你说“我们的代码库不适合简单的测试”时，这是代码气味的第一个迹象。编写单元测试意味着您通常以不同的方式编写代码，以使代码更具可测试性。在我看来，这是一件好事，因为多年来我在编写代码时看到我必须为其编写测试，这迫使我提出更好的设计。

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

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

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

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

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

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

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