代码之家 › 专栏 › 技术社区 › Stephen Melrose

单元测试分离

phpunit design-patterns unit-testing php

Stephen Melrose · 技术社区 · 15 年前

这个问题与phpunit有关,尽管应该是一个全球性的设计问题。

我在为一门课写一个单元测试用例 Image .

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

这个方法需要测试4种不同的行为,

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

目前,在我的测试用例中,所有这些都包含在一个测试中 testSetBackgroundColor() 不过,我觉得这应该是4个独立的测试,因为测试时间越来越长,而且做了很多。

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

testSetBackgroundColorErrors
testSetBackgroundColorShorthandRGB
testSetBackgroundColorRGB
testSetBackgroundColorTransparent

我在这里对考试提出了质疑 http://pastebin.com/f561fc1ab .

感谢

4 回复 | 直到 12 年前

Ivan Krechetov 15 年前

拆开它。当然。

当一个单元测试失败时,必须立即清除到底是什么被破坏了。如果你结合测试,你会调试单元测试失败。

顺便问一下,你是吗 writing tests first ?有了TDD,它不太可能以膨胀的测试结束。

Paolo 15 年前

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

它使测试失败时出现的问题更加明显,因此调试速度更快。
您可以在测试条件之间将对象重置为干净的启动状态。
只需查看方法名,就可以更容易地看到包含/省略了哪些测试。

Dave Sims 15 年前

我在概念上将我的测试分为两类(相当多的TDD从业者这样做):集成测试和单元测试。单元测试应该测试一件事,并且我应该在任何给定的时刻对我正在编写的单个契约进行测试——一般来说,一个方法需要一个测试。这迫使我写一些小的、可测试的方法,我对此有很高的信心。这反过来又倾向于引导我编写小型的可测试类。

集成测试是更高级别的测试,它证明了组件之间的交互关系,否则就被证明可以通过单元测试隔离工作。我写得更少,而且它们必须被明智地应用,因为永远不会有完全的集成级覆盖。这些重点是证明不同组件之间交互的风险更大的领域,并且可以使用书面验收测试作为指南。

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

PaulC 12 年前

是的,你应该把这些分成四个测试。也许你不愿意,因为它会复制代码。我读了一篇文章,认为单元测试应该非常可读(对不起,我没有参考资料)。它继续讨论如何做到这一点,但其要点是编写实用函数。