Question

我在TDD环境中工作并且我使用了很多其他方法，例如assert equals等。我有一个类，我有超过40个测试用例，它们都是assertTrue。这可以接受吗？

我想问一个风格，这是正确的吗？

有什么建议吗？

如果你认为这个问题不合适，请告诉我，我会删除它。

编辑：

    assertTrue(targetSpecifiers.size() == 2);
    assertTrue(targetSpecifiers.get(0).getPlacementId().compareTo(new BigInteger("1")) ==0);
    assertTrue(targetSpecifiers.get(1).getPlacementId().compareTo(new BigInteger("2")) ==0);

Answer 1

使用其他断言的主要好处是，它们可以更好地传达意图，并且可以在发生故障时提供更有意义的默认消息。

e.g。

如果assertEquals(2, x)如果x实际为1，则写入java.lang.AssertionError: expected:<2> but was:<1>，则失败消息将为：

assertTrue(x == 2)

这比写AssertionError更有帮助，你可以看到{{1}}和堆栈跟踪。

当您使用TDD时，这一点更为重要，因为当您首先编写失败的测试时，您希望确信测试失败的原因是您期望它并且没有发生意外行为

Answer 2

在适当的情况下，您应该使用正确的assertXXX方法，因为它们可以改进故障报告。对于例如如果你正在测试相等的让我们说2字符串“abc”（预期）和“abxy”（实际），那么使用 assertEquals

assertEquals("abc", "abxy")

将提供比使用 assertTrue 更容易推理的更好的输出

assertTrue("abc".equals("abxy"))

注意：还要注意指定实际和预期参数的位置。我看到许多开发人员没有遵循约定（junit的约定），期望应该是assertXXX方法的第一个参数。使用不当也会导致很多混乱

Answer 3

我的猜测是你有类似的东西：

assertTrue(expectedValue.equals(actualValue));

那仍然会测试正确的事情 - 但是当出现故障时，所有它可以告诉你断言失败了。如果您使用此代码：

assertEquals(expectedValue, actualValue);

...然后失败会说“预期：5;是：10”或类似的东西，这使得更容易弄清楚正在发生的事情。

除非您断言返回boolean或类似内容的方法的结果，否则我发现assertTrue很少有用。

如果您可以举例说明您的断言，我们可以将它们转换为更惯用的断言。

Answer 4

这些断言完全有效，但其他断言更易于阅读并提供更好的失败消息。

我建议查看Hamcrest-这提供了最易读的断言和失败消息。

的例子

assertTrue(targetSpecifiers.size() == 2);
assertTrue(targetSpecifiers.get(0).getPlacementId().compareTo(new BigInteger("1")) ==0);
assertTrue(targetSpecifiers.get(1).getPlacementId().compareTo(new BigInteger("2")) ==0);

可以改写为

assertThat(targetSpecifiers, hasSize(2));
assertThat(targetSpecifiers.get(0).getPlacementId(), equalTo(BigInteger.valueOf(1));
assertThat(targetSpecifiers.get(1).getPlacementId(), equalTo(BigInteger.valueOf(1));

或者甚至更简洁

assertThat(targetSpecifiers, contains(
    hasProperty("placementId", equalTo(BigInteger.valueOf(1)),
    hasProperty("placementId", equalTo(BigInteger.valueOf(2))
);

contains验证完整性和顺序，因此这涵盖了所有三个断言。

使用assertTrue与其他人进行单元测试

4 个答案: