涵盖功能的许多测试用例-phpunit

对于以下功能,我需要编写更多的测试用例,我已经编写了一个,可以有人给出一些想法,也许可以测试中间函数调用的返回值.

 public function calculateShortestPath($graphObj, $start, $destination)
{
    $shortestPath = null;

    if ($this->validateParams($graphObj, $start, $destination) == true) {

        $result = $this->getAllVerticesAndNeighbours($graphObj);

        $vertices = $result[self::VERTICES];
        $neighbours = $result[self::NEIGHBOURS];

        $vertexCost = array_fill_keys($vertices, self::INFINITY);
        $visitedVertices = array_fill_keys($vertices, null);

        $vertexCost[$start] = 0;
        $vertexQueue = $vertices;

        $result = $this->getShortestPath($vertexQueue, $vertexCost, $neighbours, $visitedVertices, $destination);

        $vertexCost = $result[self::VERTEX_COST];
        $shortestPathVertices = $result[self::SHORTEST_PATH_VERTICES];

        $path = $this->getRefinedShortestPath($shortestPathVertices, $destination);

        $shortestPath = new ShortestPath($path, $vertexCost[$destination]);

    }

    return $shortestPath;
}

我已经写了以下案例

 /**
 * Test for calculateShortestPath function
 *
 * @param string|int $start starting point
 * @param string|int $destination destination point
 * @param array $expectedShortestPath expected shortest path
 * @param int|float $expectedCost expected cost
 * @dataProvider testCalculateShortestPathDataProvider
 */
public function testCalculateShortestPath($start, $destination, $expectedShortestPath, $expectedCost)
{
    $actualResult = $this->shortestPathCalc->calculateShortestPath($this->graph, $start, $destination);

    /* @var $actualResult ShortestPath */
    $this->assertEquals(
        $expectedShortestPath,
        $actualResult->getPath(),
        sprintf('Incorrect shortest path from %d to %d !', $start, $destination)
    );

    $this->assertEquals(
        $expectedCost,
        $actualResult->getCost(),
        sprintf('Incorrect shortest path cost from %d to %d !', $start, $destination)
    );
}

解决方法:

通常,单元测试应表现出两个特征：

>每个测试只能测试一件事
>每个测试都应该尽可能地愚蠢

第一个特征的原因是,如果测试失败,它将记录哪个测试案例方法触发了失败.如果该方法测试了很多东西,那么确定确切的故障就更麻烦了.

之所以存在第二个特征,是因为每次测试失败都会出现问题.该问题只能存在于以下两个位置之一(忽略PHP及其扩展程序或单元测试程序中的错误)：被测试的代码或测试本身. “聪明”的测试将很难确定是哪种情况,并且您不想花一两个小时寻找类中的错误,而事实证明这实际上是测试的错误.

在上面的示例中,您当前的测试相当不错,但是它违反了第一个规则(一次有两个测试在进行).除非运行所测试的方法确实非常昂贵,否则值得将这个测试用例进行两次,第一次运行声明期望的最短路径,第二次运行声明期望的成本(如果您的方法确实有昂贵的运行时间,则有一个鼓励尝试在那里进行优化：)).

您的测试也可能违反第二条规则,因为我不知道$this->是什么.图形是或如何设置的.这是实际的业务对象还是仅仅是其模型？您可能想要研究PHPUnit的模拟存根功能.

关于测试策略,有两种通用方法：黑盒测试(在其中您根据设备的规格测试设备,但对它的内部工作情况一无所知)和玻璃盒(在其中使用对设备的内部工作的知识来进行测试).设计测试).我的首选方法是主要采用黑盒策略,围绕规格构建测试,然后在完全了解规格后,转到玻璃盒策略以编写其他测试,该测试将覆盖黑盒测试的所有代码路径不运动.

测试通常是关于边界的,就像在输入有效和无效时测试对输入的响应一样.因此,对于您的类具有的每种方法,您都需要一种典型的情况(通常称为“快乐之路”)来说明典型的用法,一些极端但仍然有效的输入,一系列超出有效范围的输入(如果您的方法会排除1-10之间的数字,然后用0的测试用例和用11的测试用例来覆盖那些用例)和用数据超出有效范围的测试用例.在有效输入和无效输入之间的转换时会发生很多编程错误(最著名的例子就是“一一错误”),因此您的测试应彻底覆盖这些区域.

黑盒测试的一个好处是,如果您了解规范,则可以在没有任何代码可以测试之前就编写测试.然后,您可以开始实施代码,对其进行测试,针对失败的测试进行更正,然后重复此过程,直到获得100％的通过率.这称为测试驱动开发.

标签：unit-testing,symfony,phpunit,php
来源： https://codeday.me/bug/20191120/2045568.html