单元测试分离答案

【问题标题】：Unit tests separation单元测试分离
【发布时间】：2010-01-21 10:46:12
【问题描述】：

这个问题与 PHPUnit 相关，虽然它应该是一个全球性的 xUnit 设计问题。

我正在为 Image 类编写单元测试用例。

这个类的方法之一是setBackgroundColor()。

我需要为此方法测试 4 种不同的行为，

试图设置无效的背景颜色。将测试多个无效参数。
尝试使用简写 RGB 数组设置有效的背景颜色，例如array(255,255,255)
尝试使用标准 RGB 数组设置有效的背景颜色，例如array('red' => 255, 'green' => 255, 'blue' => 255)（这是GD函数imagecolorsforindex()的输出格式）
尝试使用透明常量IMG_COLOR_TRANSPARENT 设置有效的背景颜色

目前，我在名为testSetBackgroundColor() 的测试用例中将所有这些都包含在 1 个测试中，但是我觉得这些应该是 4 个单独的测试，因为测试变得很长并且做了很多工作。

我的问题是，我应该在这里做什么？我是将所有这些封装到 Image 测试用例的 1 个测试中，还是将上述内容拆分为单独的测试，例如，

我在http://pastebin.com/f561fc1ab 提出了测试问题。

谢谢

【问题讨论】：

【解决方案1】：

拆分它。绝对的。

当单元测试失败时，必须立即清楚究竟是什么被破坏了。如果组合测试，您将调试单元测试失败。

顺便问一下，你是writing tests first吗？使用 TDD 不太可能导致臃肿的测试。

【讨论】：

【解决方案2】：

我的偏好是按照您的描述拆分测试。

【讨论】：

出于兴趣，您是否会将以下测试拆分为两个单独的测试，一个用于错误，一个用于通过，或者由于 dataProvider 的原因可以作为一个测试吗？ pastebin.com/f5365ed9d
我认为这没问题。数据提供者的使用是（AFAIUI）自动调用具有多个输入的相同测试的一种巧妙方法。它将突出显示哪组输入导致了任何问题，因此这满足了我列表中的前两点。您还可以轻松查看测试集，所以我想说这也涵盖了最后一点。
我希望是这样。谢谢！

【解决方案3】：

我在概念上将我的测试分为两类（正如许多 TDD 从业者所做的那样）：集成测试和单元测试。单元测试应该测试一件事，并且我应该在任何给定时刻测试我正在编写的单个合同 - 通常一种方法需要一次测试。这迫使我编写我高度信任的小型可测试方法。这反过来又会引导我编写小型可测试类。

集成测试是更高级别的测试，用于证明组件之间的交互问题，否则这些组件会被单元测试单独证明可以按预期工作。我写的更少，并且必须明智地应用它们，因为永远不可能有完整的集成级别覆盖。这些专注于证明各种组件之间交互的风险较高的领域，并且可以使用书面验收测试作为指导。

识别需要集成测试的领域更多的是一种“感觉”。如果您已经对单元测试进行了训练，那么您应该对集成测试的需求有一个很好的了解，即那些具有更深调用堆栈或跨进程交互的区域或您知道风险较高的类似区域。或者，您可能认为集成测试是证明映射到产品所有者书面要求的高级行为期望的好方法。这也是一个很好的用途。

【讨论】：

【解决方案4】：

是的，您应该将这些测试分成四个测试。也许您不愿意，因为它会重复代码。我读过一篇文章，认为单元测试应该非常可读（抱歉，我没有参考资料）。它继续讨论如何做到这一点，但它的要点是编写实用函数。

【讨论】：