单元测试是一种实践，以确保您将要实现的功能或模块的行为符合预期(需求)，并确保它在边界条件和无效输入等场景下的行为。

xUnit, NUnit, mbUnit等都是帮助你编写测试的工具。

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

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

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

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

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

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

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

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

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可以测试边缘情况——当代码被告知要做程序员不打算做的事情时，它的行为如何，而客户可以进行验收测试——代码是否按照客户的要求去做)

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

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

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

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

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

单元测试，粗略地说，就是在与测试代码隔离的情况下测试代码。我想到的直接优势是:

测试的运行变得自动化和可重复 您可以在更细粒度的级别上进行测试，而不是通过GUI进行点击测试

请注意，如果您的测试代码写入文件、打开数据库连接或在网络上执行某些操作，则更适合将其归类为集成测试。集成测试是一件好事，但不应将其与单元测试混淆。单元测试代码应该简短、简单且易于执行。

另一种看待单元测试的方法是先编写测试。这被称为测试驱动开发(简称TDD)。TDD带来了额外的优势:

您不需要编写推测性的“我将来可能需要这个”代码——只要能够通过测试即可 您编写的代码总是会被测试覆盖 通过先编写测试，您不得不考虑如何调用代码，从长远来看，这通常会改善代码的设计。

如果你现在还没有做单元测试，我建议你现在就开始做。找一本好书，实际上任何xUnit-book都可以，因为它们之间的概念可以很好地转换。

有时编写单元测试会很痛苦。当出现这种情况时，试着找个人来帮助你，并抵制住“只写该死的代码”的诱惑。单元测试很像洗碗。这并不总是令人愉快的，但它让你的比喻厨房保持干净，而你真的希望它干净。：）

编辑:我想到了一个误解，虽然我不确定它是否普遍。我曾听一个项目经理说过，单元测试让团队把所有的代码都写了两次。如果它看起来和感觉是那样的，那么，你做错了。编写测试通常不仅可以加快开发速度，而且还为您提供了一个方便的“现在我完成了”指示器，否则您就不会有这个指示器。

在单元测试和TDD的哲学优势方面，这里有一些关键的“灯泡”观察，这些观察在我试探性地走上TDD启蒙之路的第一步时打动了我(没有原创或一定是新闻)……

TDD does NOT mean writing twice the amount of code. Test code is typically fairly quick and painless to write and is a key part of your design process and critically. TDD helps you to realize when to stop coding! Your tests give you confidence that you've done enough for now and can stop tweaking and move on to the next thing. The tests and the code work together to achieve better code. Your code could be bad / buggy. Your TEST could be bad / buggy. In TDD you are banking on the chances of BOTH being bad / buggy being fairly low. Often its the test that needs fixing but that's still a good outcome. TDD helps with coding constipation. You know that feeling that you have so much to do you barely know where to start? It's Friday afternoon, if you just procrastinate for a couple more hours... TDD allows you to flesh out very quickly what you think you need to do, and gets your coding moving quickly. Also, like lab rats, I think we all respond to that big green light and work harder to see it again! In a similar vein, these designer types can SEE what they're working on. They can wander off for a juice / cigarette / iphone break and return to a monitor that immediately gives them a visual cue as to where they got to. TDD gives us something similar. It's easier to see where we got to when life intervenes... I think it was Fowler who said: "Imperfect tests, run frequently, are much better than perfect tests that are never written at all". I interprete this as giving me permission to write tests where I think they'll be most useful even if the rest of my code coverage is woefully incomplete. TDD helps in all kinds of surprising ways down the line. Good unit tests can help document what something is supposed to do, they can help you migrate code from one project to another and give you an unwarranted feeling of superiority over your non-testing colleagues :)

这篇演讲很好地介绍了测试所需要的所有内容。