我在FoxForward 2007参加了一个关于单元测试的演讲，被告知永远不要对任何与数据相关的东西进行单元测试。毕竟，如果您在实时数据上进行测试，结果是不可预测的，如果您不在实时数据上进行测试，那么实际上并不是在测试您所编写的代码。不幸的是，这是我最近编写的大部分代码。: -)

最近，当我编写一个保存和恢复设置的例程时，我确实尝试了TDD。首先，我验证了是否可以创建存储对象。然后，它有我需要调用的方法。然后，我可以称之为。然后，我可以给它传递参数。然后，我可以给它传递特定的参数。依此类推，直到我最终验证它将保存指定的设置，允许我更改它，然后为几种不同的语法恢复它。

我没看完，因为我现在需要例行公事，但这是一个很好的练习。

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

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

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

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

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

使用Testivus。你需要知道的都在那里:)

这回答了为什么您应该进行单元测试。

下面的三个视频涵盖了javascript中的单元测试，但一般原则适用于大多数语言。

单元测试:现在的几分钟将节省几小时后- Eric Mann - https://www.youtube.com/watch?v=_UmmaPe8Bzc

JS单元测试(非常好)- https://www.youtube.com/watch?v=-IYqgx8JxlU

编写可测试的JavaScript - https://www.youtube.com/watch?v=OzjogCFO4Zo

Now I'm just learning about the subject so I may not be 100% correct and there's more to it than what I'm describing here but my basic understanding of unit testing is that you write some test code (which is kept separate from your main code) that calls a function in your main code with input (arguments) that the function requires and the code then checks if it gets back a valid return value. If it does get back a valid value the unit testing framework that you're using to run the tests shows a green light (all good) if the value is invalid you get a red light and you then can fix the problem straight away before you release the new code to production, without testing you may actually not have caught the error.

So you write tests for you current code and create the code so that it passes the test. Months later you or someone else need to modify the function in your main code, because earlier you had already written test code for that function you now run again and the test may fail because the coder introduced a logic error in the function or return something completely different than what that function is supposed to return. Again without the test in place that error might be hard to track down as it can possibly affect other code as well and will go unnoticed.

Also the fact that you have a computer program that runs through your code and tests it instead of you manually doing it in the browser page by page saves time (unit testing for javascript). Let's say that you modify a function that is used by some script on a web page and it works all well and good for its new intended purpose. But, let's also say for arguments sake that there is another function you have somewhere else in your code that depends on that newly modified function for it to operate properly. This dependent function may now stop working because of the changes that you've made to the first function, however without tests in place that are run automatically by your computer you will not notice that there's a problem with that function until it is actually executed and you'll have to manually navigate to a web page that includes the script which executes the dependent function, only then you notice that there's a bug because of the change that you made to the first function.

重申一下，在开发应用程序时运行测试将在编写代码时发现这类问题。如果没有适当的测试，你必须手动检查整个应用程序，即使这样也很难发现错误，你天真地将其发送到生产环境中，一段时间后，好心的用户会给你发送错误报告(这不会像你在测试框架中的错误消息那样好)。

It's quite confusing when you first hear of the subject and you think to yourself, am I not already testing my code? And the code that you've written is working like it is supposed to already, "why do I need another framework?"... Yes you are already testing your code but a computer is better at doing it. You just have to write good enough tests for a function/unit of code once and the rest is taken care of for you by the mighty cpu instead of you having to manually check that all of your code is still working when you make a change to your code.

此外，如果你不想进行单元测试，你也不必进行单元测试，但随着你的项目/代码库开始变得越来越大，引入错误的可能性也在增加，这是值得的。