Question

我使用TDD开发俄罗斯方块游戏。现在我正在测试Field类的isEmpty（）方法。

我已经编写了三个测试用例：

@Test
public void shouldIsEmptyMethodReturnTrueForEmptyField() {
    Field field = Field.createStandartEmptyField();
    assertTrue(field.isEmpty());
}

@Test
public void shouldIsEmptyMethodReturnFalseIfCellInLowerLeftCornerIsFilled() {
    Field field = Field.createStandartEmptyField();
    field.fillCellAt(0, 0);
    assertFalse(field.isEmpty());
}

@Test
public void shouldIsEmptyMethodReturnFalseIfCellInLowerRightCornerIsFilled() {
    Field field = Field.createStandartEmptyField();
    field.fillCellAt(field.getWidth() - 1, 0);
    assertFalse(field.isEmpty());
}

我的isEmpty（）方法看起来像这样

public boolean isEmpty() {
    if (isFilledCellAt(0, 0)) {
        return false;
    }
    if (isFilledCellAt(getWidth() - 1, 0)) {
        return false;
    }
    return true;
}

所以我可以进一步编写新的测试用例来测试俄罗斯方块领域中每个填充细胞的组合。 当我不得不停下来？使用TDD测试tetris Field类的isEmpty（）方法的正确方法是什么？

Answer 1

Equivalence partitioning可以帮助您减少要编写的测试用例的数量。在这里，你可以举例说明3例：[NoCells，OneCell，ManyCells]。

Boundary Value Analysis是一种补充方法，但它更适用于采用自由输入的方法。在这里，上下文实际上不允许低于或超出极端边缘（-1个单元格或>一行中的单元格数量）。

如果您真的想测试案例组合，Property-based Testing或其他自动化测试数据生成方法可能就是您所需要的。

Answer 2

我认为这很大程度上取决于经验，而且没有简单的方法来确定你的答案。在编写测试时，我会看到：

覆盖。我是否涵盖了所有代码路径？或者至少那些我觉得会成为问题的潜在原因
输入和输出。我是否涵盖所有可能的输入和输出组合。在某些情况下，这是不切实际的（例如，如果你的方法需要一个整数来添加到另一个，你会传入1,2,3 ....）
边缘情况。我的代码是否正确处理边界条件？

因此，当我编写代码时，我会感觉到我需要断言的有问题的场景，以及我编写的每一行代码是否都以某种方式被覆盖。如果我有相当数量的输入/输出场景要覆盖，我会考虑实现一个输入/输出表来断言并让测试框架总共执行每个（例如Groovy的Spock使这很容易.Junit的Parameterized Tests是另一种实现方式）

Answer 3

这在很大程度上取决于个人偏好。但是，如果您想遵循严格的TDD，那么一旦您不再编写损坏的测试，您将希望停止。首先编写一个失败的测试，并编写足够的代码来通过该测试。然后你编写下一个失败的测试并继续更新你的代码和重构，直到一切都是绿色。如果你不能再编写失败的测试，那么你就不需要再编写测试了。

何时停止在TDD中进行测试

3 个答案: