我不反对丹的观点(尽管不回答可能是更好的选择)……但是……

单元测试是编写代码来测试系统的行为和功能的过程。

显然，测试可以提高代码的质量，但这只是单元测试的表面好处。真正的好处是:

Make it easier to change the technical implementation while making sure you don't change the behavior (refactoring). Properly unit tested code can be aggressively refactored/cleaned up with little chance of breaking anything without noticing it. Give developers confidence when adding behavior or making fixes. Document your code Indicate areas of your code that are tightly coupled. It's hard to unit test code that's tightly coupled Provide a means to use your API and look for difficulties early on Indicates methods and classes that aren't very cohesive

你应该进行单元测试，因为向客户交付可维护的高质量产品符合你的利益。

我建议您将它用于任何系统，或系统的一部分，以模拟真实世界的行为。换句话说，它特别适合于企业开发。我不会将它用于一次性/实用程序。我不会用它来测试系统中有问题的部分(UI是一个常见的例子，但并不总是这样)

最大的陷阱是开发人员测试太大的单元，或者他们认为一个方法是一个单元。如果您不理解控制反转，这一点尤其正确——在这种情况下，您的单元测试总是会变成端到端集成测试。单元测试应该测试单个行为——大多数方法都有许多行为。

最大的误解是程序员不应该测试。只有糟糕或懒惰的程序员才会相信这一点。给你盖屋顶的人不应该测试吗?更换心脏瓣膜的医生不应该检查新瓣膜吗?只有程序员才能测试他的代码是否按照他的意图去做(QA可以测试边缘情况——当代码被告知要做程序员不打算做的事情时，它的行为如何，而客户可以进行验收测试——代码是否按照客户的要求去做)

单元测试是在不需要该代码单元所依赖的基础设施的情况下对代码单元(例如单个函数)进行测试。即在隔离环境中进行测试。

例如，如果您正在测试的函数连接到数据库并执行更新，那么在单元测试中您可能不想执行该更新。如果这是一个积分测试，你会这样做，但在这个例子中，它不是。

因此，单元测试将测试您正在测试的“函数”中所包含的功能，而不会产生数据库更新的副作用。

假设函数从数据库中检索了一些数字，然后执行标准偏差计算。你想测试什么?标准偏差计算正确，还是数据从数据库返回?

在单元测试中，您只想测试标准偏差的计算是否正确。在集成测试中，您希望测试标准偏差计算和数据库检索。

如果你想使用Kent Beck推广的TDD方法开发项目，像NUnit、xUnit或JUnit这样的库是必须的:

你可以阅读《测试驱动开发介绍》(TDD)或Kent Beck的《测试驱动开发:举例说明》。

然后，如果你想确保你的测试覆盖了代码中“好的”部分，你可以使用NCover、JCover、PartCover或其他软件。它们会告诉你代码的覆盖率。取决于你对TDD的熟练程度，你会知道你是否已经很好地练习了它:)

如果给你一堆垃圾，你似乎陷入了一种永久的清理状态，你知道任何新功能或代码的添加都会破坏当前的设置，因为当前的软件就像一个纸牌屋，你会怎么做? 那么我们如何进行单元测试呢?

从小事开始。我刚加入的项目直到几个月前才开始进行单元测试。当覆盖率如此之低时，我们将简单地选择一个没有覆盖率的文件并单击“添加测试”。

现在我们已经达到了40%以上，我们已经成功地摘走了大部分容易摘到的果实。

(最好的部分是，即使在这样低的覆盖率水平上，我们已经遇到了许多代码做错误事情的实例，并且测试发现了它。这是促使人们增加更多测试的巨大动力。)

单元测试和TDD通常能让你对所编写的软件有更短的反馈周期。与在实现的最后有一个大型测试阶段不同，您可以增量地测试您所编写的所有内容。这大大提高了代码质量，正如您立即看到的那样，您可能会有错误。

单元测试是关于编写测试应用程序代码的代码。

名称的Unit部分是关于一次测试小单元代码(例如一个方法)的意图。

xUnit是用来帮助测试的——它们是帮助测试的框架。其中一部分是自动测试运行器，它会告诉您哪些测试失败，哪些测试通过。

它们还可以在每个测试之前设置您需要的公共代码，并在所有测试完成后将其删除。

您可以使用一个测试来检查是否抛出了预期的异常，而不必自己编写整个try catch块。