Unit testing 什么是单元测试？

我看到很多问题问“如何”用特定语言进行单元测试，但没有问题问“什么”、“为什么”和“何时”

• 这是什么
• 这对我有什么好处
• 我为什么要用它
• 我应该在什么时候使用它（也应该在不使用的时候）
• 有哪些常见的陷阱和误解

---

粗略地说，单元测试是在测试代码与代码隔离的情况下测试代码位。我想到的直接好处是：

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

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

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

• 您不需要编写推测性的“我将来可能需要这个”代码——只需编写足以使测试通过的代码即可
• 您编写的代码总是包含在测试中
• 通过先编写测试，您不得不考虑如何调用代码，这通常会从长远来看改进代码的设计

如果您现在没有进行单元测试，我建议您开始进行单元测试。得到一本好书，实际上任何一本xUnit的书都可以，因为它们之间的概念非常容易转移

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

---

编辑：我想到了一个误解，尽管我不确定它是否如此普遍。我听一位项目经理说，单元测试让团队将所有代码编写了两次。如果它看起来和感觉都是这样，那么，你做错了。编写测试不仅通常会加快开发速度，而且它还为您提供了一个方便的“现在我完成了”指标，这是您在其他情况下无法做到的。

我不同意Dan的观点（尽管更好的选择可能是不回答）…但是

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

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

在确保不更改行为（重构）的同时，更容易更改技术实现。经过适当单元测试的代码可以被积极地重构/清理，几乎不可能在没有注意到的情况下破坏任何东西

在添加行为或进行修复时给开发人员信心

记录您的代码

指出代码中紧密耦合的区域。很难对紧密耦合的代码进行单元测试

提供一种使用API的方法，并在早期查找困难

指示内聚性不强的方法和类

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

我建议您将其用于模拟真实世界行为的任何系统或系统的一部分。换句话说，它特别适合企业开发。我不会将其用于一次性/实用程序。我不会将它用于测试有问题的系统部分（UI是一个常见的示例，但情况并非总是如此）

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

---

最大的误解是程序员不应该测试。只有糟糕或懒惰的程序员才会相信这一点。盖你屋顶的人不应该测试一下吗？更换心脏瓣膜的医生是否应该不测试新瓣膜？只有程序员才能测试自己的代码是否达到了预期的效果（QA可以测试边缘案例——当被告知要做程序员不想做的事情时，代码的行为如何，客户可以进行验收测试——代码是否达到了客户花钱让它做的事情）

这是我的看法。我想说的是，单元测试是编写软件测试的实践，以验证您的真实软件是否达到了预期目的。这始于Java世界，并已成为PHP以及和的最佳实践。它是极限编程的核心实践，帮助您确保您的软件在编辑后仍能按预期工作。如果您有足够的测试覆盖率，您可以快速地进行主要的重构、bug修复或添加特性，而不必担心引入其他问题

当所有单元测试都可以自动运行时，它最有效

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

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