2010-01-21 61 views
4

这个问题与PHPUnit有关,虽然它应该是是一个全局xUnit设计问题。单元测试分离

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

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

有4周不同的行为我需要测试该方法,

  1. 试图设置一个无效的背景颜色。多个无效参数将被测试。
  2. 尝试使用短手RGB数组设置有效的背景色,例如array(255,255,255)
  3. 尝试使用标准RGB数组设置有效背景色,例如array('red' => 255, 'green' => 255, 'blue' => 255)(这是GD功能imagecolorsforindex()的输出格式)
  4. 试图使用透明恒定IMG_COLOR_TRANSPARENT

目前设置有效的背景颜色,我已经此包含的所有1次测试中在我的测试的情况下叫做testSetBackgroundColor(),但是我感觉这些应该是4个单独的测试,因为测试变得相当长并且做了很多。

我的问题是,我应该在这里做什么?我封装到所有这些图像测试用例1周的测试,或做我分裂到上述像单独的测试,

  • testSetBackgroundColorErrors
  • testSetBackgroundColorShorthandRGB
  • testSetBackgroundColorRGB
  • testSetBackgroundColorTransparent

我在这里把这个测试放在这里http://pastebin.com/f561fc1ab

谢谢

+0

+1,很好的问题,写得很好。 – Grundlefleck 2010-01-21 12:23:15

回答

7

拆分它。绝对。

当单元测试失败时,必须立即清除究竟是什么被破坏。如果结合测试,你将会在调试单元测试失败。

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

+0

几乎我的想法,只是想听听别人。干杯。 – 2010-01-21 10:52:30

+0

刚看到你最后一个问题。我在这个课上做错了,但是我从现在开始使用TDD,因为我看到了好处。 – 2010-01-21 11:04:00

3

我的偏好是按照你描述的方法拆分测试。

  • 这使得它更加明显,当测试失败什么出了问题,因此更快地调试
  • 你得到的对象的复位的好处干净的起始状态的测试条件之间
  • 这使得它更容易看到你已经列入/省略了测试只是看着方法名
+0

出于兴趣,您是否将以下内容分为两个单独的测试,一个用于错误,另一个用于通过,还是因为dataProvider而可以确定为一个测试? http://pastebin.com/f5365ed9d – 2010-01-21 11:01:59

+0

这是好的,因为我认为。数据提供者的使用(AFAIUI)是一种自动调用多个输入的相同测试的简便方法。它会突出显示哪一组输入引起了任何问题,因此这满足了我列表中的前两点。你也可以很容易地看到测试集,所以我会说覆盖最后一点。 – Paolo 2010-01-21 11:12:40

+0

我当时就是这么想的。谢谢! – 2010-01-21 12:02:29

0

我概念性分割我的测试分为两个类别(如相当多的TDD从业者):集成测试和单元测试。单元测试应该测试一件事情,并且我应该遵守测试我在任何时候编写的单一合同的规定 - 通常一种方法需要一次测试。这迫使我写出一些我可以高度自信的小型可测试方法,这反过来倾向于指导我编写小型可测试类。

集成测试是更高级别的测试,可以证明组件之间的交互关系,否则这些组件之间会被单元测试隔离开来。我写的这些数量较少,而且必须谨慎应用,因为永远不可能有完整的集成级别覆盖。这些重点是证明各个组件之间相互作用的高风险区域,并且可以使用书面验收测试作为指导。

识别需要集成测试的领域更多的是“感觉”。如果你已经接受过单元测试的训练,那么你应该对集成测试需求有一个好主意,也就是那些有更深层次调用或跨进程交互的领域,或者你知道存在更高风险的领域。或者,您可以决定集成测试是证明映射到产品所有者书面要求的高级行为预期的好方法。这也是一个很好的用法。

0

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