我试图进入单元测试,因为它引入了一些明显的优点,我还试图为我前几天编写的一个类编写一个单元测试。(我知道这与TDD正好相反,请容忍我)
我的类Image
与其他类一起用于图像处理。
Image
本质上封装了GD图像资源并存储数据。例如,Image
的实例将始终包含它的当前状态,即如果调整大小,它的新宽度/高度、原始图像数据等等。
Image
类还包含
$image->loadFromPath()
Image
实例的属性创建新的GD图像资源,例如用于图像调整以保持背景透明度等。我正在苦苦挣扎的是如何用PHPUnit正确地测试这个类。我读过一些书,对于如何处理它,我有一些相互矛盾的想法,但我不知道什么是正确的。我有,
那么,哪一个是正确的,如果有的话?
发布于 2010-01-20 08:54:19
应该编写单元测试来评估类的公共接口。您的测试用例应该像您希望在程序中使用的那样使用这个类。这里的想法是测试类的行为(可能是预期的、意外的或边缘条件)。
你发表的两个观点都是正确的。理论上,您应该有足够的测试用例(通过代码进行路由),使类中的所有方法都能运行。
如前所述,100%的测试覆盖率是一个不错的目标,但并不总是现实的。
另外,在GD的情况下,在编写测试GD功能的单元测试时要小心(它已经过测试,您不需要浪费时间再次测试它)。我将在读懂手册中使用PHPUnit的模拟和存根(以及对文件系统的模拟)。
下面是示例测试的样子:
public function testImageIsResized()
{
$image = new Image();
$image->loadFromPath('some/path');
$image->resize(200, 300);
$this->assertEquals(200, $image->getWidth());
$this->assertEquals(300, $image->getHeight());
}
现在,取决于图像类的预期行为,这个测试可能通过而没有问题,或者它可能会失败,因为它期望新的维度按比例被约束到原始的图像维度。但是,我们没有显式地调用检查测试本身中该约束的内部方法。
发布于 2010-01-20 08:15:11
您可以使用注解指定测试是否包括多个方法。因此,如果您的方法之一调用另一个方法,您可以简单地将注释添加到测试的docblock中,并将其添加到代码覆盖率统计信息中。
/**
* @test
* @covers MyClass::something()
* @covers MyClass::_somethingElse()
*/
public function somethingWorksAsExpected()
{
$this->assertSame($expected, $this->testObject->something());
}
对于个人项目,100%的代码覆盖范围很好。然而,我在会议上看到了100%的怀疑是必要的。尽管有所有的好处,但是测试需要时间来编写,而在一个预算项目中,只测试80/20就足够了,而忽略了应用程序不重要的低优先级特性。
至于如何测试您的类,请看一看关于PHPUnit手册中的行为驱动开发的章节。在您的情况下,我将测试您在问题中描述的功能。
发布于 2011-05-25 17:45:40
斯蒂芬·梅罗斯说:
但是,有些方法运行其他方法(我可以添加),因此您有一个依赖链。但我也读到每个单元测试应该独立于另一个单元测试
测试独立性不在于不对同一代码进行两次测试,而是一个测试的结果(或缺少结果)是否会影响另一个测试的结果。如果第一个测试插入了一些数据,然后在数据删除之前失败,那么第二个测试的结果可能与预期不同。理想情况下,您应该能够以随机顺序运行您的测试,或者运行一些而不是其他。
https://stackoverflow.com/questions/2102690
复制相似问题