单元测试的全部意义在于使测试变得简单。这是自动的。“make test”就完成了。如果您面临的问题之一是难以测试代码，那么这就是使用单元测试的最佳理由。

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.

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

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

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

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

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

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

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

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

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

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