許多測試用例涵蓋了一個函數 - phpunit

Question

對於以下函數，我需要編寫更多的測試用例，我已經編寫了一個，可以有人給出一些想法，也許是為了測試中間函數調用的返回值。

 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)
    );
}

Answer 1

作為一般規則，單元測試應該表現出兩個特征：

• 每個測試都應測試一個且只測試一件事
• 每項測試都應盡可能愚蠢

第一個特征的原因是如果測試失敗，它將記錄哪個測試用例方法觸發了失敗。 如果該方法測試了很多東西，那么確定確切的失敗就更加麻煩了。

存在第二個特征是因為每次測試失敗，都必定存在問題。 問題只能存在於兩個地方之一（忽略PHP及其擴展中的錯誤，或單元測試程序中）：在測試代碼中，或在測試本身中。 “聰明”的測試將很難確定它是哪種情況，並且你不想花一兩個小時追捕你班上的一個錯誤，而事實證明它實際上是測試的錯誤。

在上面的示例中，您當前的測試非常好，但它打破了第一條規則（一次發生了兩次測試）。 除非運行測試中的方法非常昂貴，否則可能值得將此測試用例兩次，第一次運行斷言預期的最短路徑，第二次斷言預期成本（如果您的方法確實有一個昂貴的運行時間，那么有一個激勵嘗試並優化它在那里:)）。

你的測試也可能會破壞第二條規則，因為我不知道$ this - > graph是什么或它是如何設置的。 這是一個實際的業務對象還是僅僅是一個模型？ 您可能希望研究模擬PHPUnit的存根功能。

關於測試策略，有兩種常規方法 - 黑盒測試（根據其規格測試單元，但對待它就像你不了解其內部工作原理）和玻璃盒（在那里你使用你對單元內部工作的了解）設計測試）。 我首選的方法是主要采用黑盒策略，圍繞規范構建測試，然后一旦我完全覆蓋規范，就轉向玻璃盒策略，編寫額外的測試，覆蓋黑盒測試的任何代碼路徑不運動。

測試通常與邊界有關，如在輸入有效且無效時測試對輸入的響應。 因此，對於您的課程所具有的每種方法，您需要一個典型的案例（通常稱為“快樂路徑”）來演示典型用法，一些極端但仍然有效的輸入，一系列輸入超出有效范圍（如果你的方法除了1-10范圍內的數字，然后是0的測試用例和11的測試用例將覆蓋這些情況）和一個測試用例，其數據大大超出有效范圍。 編程中的許多錯誤發生在有效輸入和無效輸入之間的轉換（逐個錯誤可能是最臭名昭着的例子），因此您的測試應該徹底覆蓋這些區域。

黑盒測試的一個好處是，如果你知道規格，你可以在任何代碼甚至測試之前編寫測試。 然后，您可以開始實現代碼，對其進行測試，針對失敗的測試進行更正並重復此過程，直到獲得100％的通過率。 這稱為測試驅動開發。