我最近在我的工作场所经历了完全相同的经历，发现大多数人都知道理论上的好处，但必须具体地向他们推销这些好处，所以下面是我使用的(成功地)要点:

它们在执行负测试(处理意外输入(空指针、越界值等)时节省了时间，因为您可以在单个进程中完成所有这些。 它们在编译时提供关于更改标准的即时反馈。 它们对于测试在正常运行时可能不会公开的内部数据表示非常有用。

还有那个大的…

您可能不需要单元测试，但是当其他人进入并在没有完全理解的情况下修改代码时，它可以捕捉到他们可能犯的许多愚蠢的错误。

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

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

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

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

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

如果您现有的代码库本身不适合单元测试，并且它已经处于生产环境中，那么通过试图重构所有代码以使其具有单元可测试性，您可能会产生比解决更多的问题。

您最好将精力放在改进集成测试上。有很多代码在没有单元测试的情况下编写起来更简单，如果QA可以根据需求文档验证功能，那么就完成了。船。

在我的脑海中，最经典的例子就是嵌入到GridView的ASPX页面中的SqlDataReader。代码都在ASPX文件中。SQL位于存储过程中。你做什么单元测试?如果页面做了它应该做的事情，那么是否真的应该将其重新设计成几个层，以便实现自动化?

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.

我曾多次尝试单元测试，我仍然相信，考虑到我的情况，这是值得的。

我开发网站，其中很多逻辑涉及在数据库中创建、检索或更新数据。当我为了单元测试的目的而尝试“模拟”数据库时，它变得非常混乱，似乎有点毫无意义。

当我围绕业务逻辑编写单元测试时，从长远来看它从未真正帮助过我。因为我主要独自从事项目工作，我倾向于直观地知道哪些代码区域可能会受到我所从事的工作的影响，并且我手动测试这些区域。我希望尽可能快地向客户交付解决方案，而单元测试通常看起来是浪费时间。我列出了手动测试，并亲自完成它们，并在执行过程中标记它们。

我可以看到，当一个开发团队在一个项目中工作并互相更新代码时，这可能是有益的，但即使这样，我认为如果开发人员具有高质量，良好的沟通和编写良好的代码通常就足够了。