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

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

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

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

One of the best things about unit testing is that your code will become easier to test as you do it. Preexisting code created without tests is always a challenge because since they weren't meant to be unit-tested, it's not rare to have a high level of coupling between classes, hard-to-configure objects inside your class - like an e-mail sending service reference - and so on. But don't let this bring you down! You'll see that your overall code design will become better as you start to write unit-tests, and the more you test, the more confident you'll become on making even more changes to it without fear of breaking you application or introducing bugs.

There are several reasons to unit-test your code, but as time progresses, you'll find out that the time you save on testing is one of the best reasons to do it. In a system I've just delivered, I insisted on doing automated unit-testing in spite of the claims that I'd spend way more time doing the tests than I would by testing the system manually. With all my unit tests done, I run more than 400 test cases in less than 10 minutes, and every time I had to do a small change in the code, all it took me to be sure the code was still working without bugs was ten minutes. Can you imagine the time one would spend to run those 400+ test cases by hand?

当涉及到自动化测试——无论是单元测试还是验收测试——每个人都认为编写可以手动完成的代码是浪费精力，有时这是真的——如果你计划只运行一次测试的话。自动化测试最好的部分是，您可以毫不费力地运行它们几次，并且在第二次或第三次运行之后，您所浪费的时间和精力已经得到了补偿。

最后一个建议是，不仅要对代码进行单元测试，还要先进行测试(详见TDD和BDD)。

这是非常以. net为中心的，但是有人尝试过Pex吗?

我非常怀疑，直到我尝试了——哇，多么精彩的表演。以前我想“我不会被这个概念说服，直到我明白它实际上对我有什么好处”。我只跑了一次就改变了主意，说:“我不在乎你怎么知道那里有致命异常的风险，但现在我知道我必须处理它”

也许这种行为唯一的缺点是它会标记所有事情，给你六个月的积压。但是，如果你有代码债，你总是有代码债，只是你不知道而已。告诉项目经理可能有20万个故障点，而你之前只知道有几十个，这是一个令人讨厌的前景，这意味着首先解释这个概念是至关重要的。

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

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

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