This is my take on it. I would say unit testing is the practice of writing software tests to verify that your real software does what it is meant to. This started with jUnit in the Java world and has become a best practice in PHP as well with SimpleTest and phpUnit. It's a core practice of Extreme Programming and helps you to be sure that your software still works as intended after editing. If you have sufficient test coverage, you can do major refactoring, bug fixing or add features rapidly with much less fear of introducing other problems.

当所有单元测试都能自动运行时，这是最有效的。

单元测试通常与OO开发相关联。基本思想是创建一个脚本，为你的代码设置环境，然后练习它;您编写断言，指定您应该接收的预期输出，然后使用如上所述的框架执行您的测试脚本。

框架将针对您的代码运行所有测试，然后报告每个测试的成功或失败。phpUnit默认情况下从Linux命令行运行，尽管有HTTP接口可用于它。SimpleTest本质上是基于web的，在我看来，它更容易启动和运行。结合xDebug, phpUnit可以为您提供代码覆盖率的自动统计数据，有些人认为这非常有用。

有些团队从他们的subversion存储库编写钩子，以便在提交更改时自动运行单元测试。

将单元测试保存在与应用程序相同的存储库中是一个很好的实践。

在单元测试和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 :)

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

我使用单元测试来节省时间。

在构建业务逻辑(或数据访问)时，测试功能通常涉及在许多屏幕上输入内容，这些内容可能尚未完成，也可能尚未完成。自动化这些测试可以节省时间。

对我来说，单元测试是一种模块化的测试工具。每个公共函数通常至少有一个测试。我编写额外的测试来覆盖各种行为。

您在开发代码时想到的所有特殊情况都可以记录在单元测试的代码中。单元测试还成为如何使用代码的示例的来源。

对我来说，在单元测试中发现我的新代码破坏了某些东西比检入代码并让前端开发人员发现问题要快得多。

对于数据访问测试，我尝试编写没有更改或自行清理的测试。

单元测试不能解决所有的测试需求。他们将能够节省开发时间并测试应用程序的核心部分。

我想推荐Gerard Meszaros的《xUnit测试模式》一书。它很大，但在单元测试方面是一个很好的资源。这里有一个链接到他的网站，在那里他讨论了单元测试的基础知识。http://xunitpatterns.com/XUnitBasics.html

测试驱动开发在某种程度上取代了单元测试这个术语。作为一个老手，我会提到它的更一般的定义。

单元测试还意味着测试一个较大系统中的单个组件。这个组件可以是dll、exe、类库等。它甚至可以是多系统应用程序中的单个系统。因此，单元测试最终是对一个更大系统的单个部分进行测试。

然后，您可以通过测试所有组件如何一起工作来进行集成测试或系统测试。

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

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

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

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

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