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

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

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

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

偶尔，我自己或我的同事会花几个小时来研究一个不太明显的错误，一旦发现了错误的原因，90%的情况下代码都没有经过单元测试。单元测试并不存在，因为开发人员为了节省时间而偷工减料，但随后却失去了这一点和更多的调试。

花少量的时间来编写单元测试可以节省未来调试的时间。

就在今天，我不得不更改一个类，之前已经为其编写了单元测试。 测试本身写得很好，包括我甚至没有想过的测试场景。 幸运的是，所有测试都通过了，我的更改很快得到了验证，并自信地放到了测试环境中。

关于单元测试要记住的一件事是，它对开发人员来说是一种安慰。

相反，功能测试是针对用户的:无论何时添加功能测试，您都是在测试用户将看到的东西。当您添加单元测试时，您只是让开发人员的生活更轻松。在这方面有点奢侈。

当您必须在编写单元或功能测试之间做出选择时，请记住这种二分法。

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

我不知道。很多地方不做单元测试，但是代码质量很好。微软做单元测试，但是比尔·盖茨在他的演示中出现了蓝屏。