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

如果你正在使用NUnit，一个简单而有效的演示就是在他们面前运行NUnit自己的测试套件。看到一个真正的测试套件对代码库进行测试，胜过千言万语……

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

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

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

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

单元测试绝对是值得付出努力的。不幸的是，您选择了一个困难的(但不幸的是常见的)场景来实现它。

从单元测试中获得的最大好处是从头开始使用它——在一些精选的小项目中，我有幸在实现类之前编写单元测试(此时接口已经完成)。通过适当的单元测试，您可以在类还处于婴儿期时就发现并修复它们，而不是在将来毫无疑问会集成到复杂系统中的任何地方。

如果您的软件是完全面向对象的，那么您应该能够在类级别上添加单元测试，而不需要太多的努力。如果您没有那么幸运，您仍然应该尽可能地尝试合并单元测试。确保当你添加新功能时，新部分都有清晰的接口，你会发现单元测试让你的工作变得更容易。

Unit testing helps a lot in projects that are larger than any one developer can hold in their head. They allow you to run the unit test suite before checkin and discover if you broke something. This cuts down a lot on instances of having to sit and twiddle your thumbs while waiting for someone else to fix a bug they checked in, or going to the hassle of reverting their change so you can get some work done. It's also immensely valuable in refactoring, so you can be sure that the refactored code passes all the tests that the original code did.

单元测试适用于QA人员或你的经理，而不是你;所以绝对不值得。

您应该专注于编写正确的代码(不管这意味着什么)，而不是测试用例。让其他人去担心吧。