unit-testing - 在单元测试中使用多个断言是一种不好的做法吗？

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

想要改进这个问题吗？更新问题，以便 editing this post 可以用事实和引文来回答它。 .

已关闭 6 年前。

Improve this question

在单元测试中使用多个断言是一种不好的做法吗？这有关系吗？

Answer 1

有时，每个测试用例只有一个 assert，但我认为更多时候我有多个 assert 语句。

我见过 @Arkain 逃避的情况，其中一段非常大的代码有一个单元测试套件，只有几个测试用例，并且它们都被标记为 testCase1，testCase2 等，每个测试用例有数百个断言。更好的是，每个条件通常都取决于先前执行的副作用。每当构建失败时，总是在这样的单元测试中，需要相当长的时间才能确定问题出在哪里。

但另一个极端是您的问题所暗示的:针对每种可能的条件都有一个单独的测试用例。根据您正在测试的内容，这可能是有意义的，但通常每个测试用例都有多个 assert。

例如，如果您编写了java.lang.Integer，您可能会遇到如下情况:

public void testValueOf() {
    assertEquals(1, Integer.valueOf("1").intValue());
    assertEquals(0, Integer.valueOf("0").intValue());
    assertEquals(-1, Integer.valueOf("-1").intValue());
    assertEquals(Integer.MAX_VALUE, Integer.valueOf("2147483647").intValue());
    assertEquals(Integer.MIN_VALUE, Integer.valueOf("-2147483648").intValue());
    ....
}

public void testValueOfRange() {
    assertNumberFormatException("2147483648");
    assertNumberFormatException("-2147483649");
    ...
}

public void testValueOfNotNumbers() {
    assertNumberFormatException("");
    assertNumberFormatException("notanumber");
    ...
}
private void assertNumberFormatException(String numstr) {
    try {
        int number = Integer.valueOf(numstr).intValue();
        fail("Expected NumberFormatException for string \"" + numstr +
             "\" but instead got the number " + number);
    } catch(NumberFormatException e) {
        // expected exception
    }
}

我可以立即想到一些简单的规则，以确定在测试用例中放置多少个断言:

• 不要有多个依赖于先前执行的副作用的断言。
• 将测试相同功能/特性或其方面的断言组合在一起 - 不必要时无需多个单元测试用例的开销。
• 上述任何规则均应以实用性和常识为依据。您可能不希望有一千个单元测试用例，每个单元测试用例(甚至多个断言)中只有一个断言，并且您也不希望单个测试用例包含数百个 assert 语句。