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

Dar*_*der 3 java junit unit-testing

我在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);
Run Code Online (Sandbox Code Playgroud)

mik*_*kej 6

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

例如

如果你写assertEquals(2, x)如果x实际上是1然后失败消息将是:

java.lang.AssertionError: expected:<2> but was:<1>
Run Code Online (Sandbox Code Playgroud)

这比你写的assertTrue(x == 2)所有你会看到的AssertionError和堆栈跟踪更有帮助.

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


Ara*_*ram 5

在适当的情况下,您应该使用正确的assertXXX方法,因为它们可以改进故障报告.例如,如果你正在测试两个字符串"abc"(预期)和"abxy"(实际)的相等性,那么使用assertEquals

assertEquals("abc", "abxy") 
Run Code Online (Sandbox Code Playgroud)

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

assertTrue("abc".equals("abxy"))
Run Code Online (Sandbox Code Playgroud)

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