为什么我要使用Hamcrest-Matcher和断言--那个()而不是传统的sertXXX()-方法?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (34)

当我查看Assert类JavaDoc中的示例时

assertThat("Help! Integers don't work", 0, is(1)); // fails:
// failure message:
// Help! Integers don't work
// expected: is <1> 
// got value: <0>
assertThat("Zero is one", 0, is(not(1))) // passes

比方说,我没有看到一个很大的优势assertEquals( 0, 1 )

如果结构变得更加复杂但是你看到更多的优势,那么也许对于这些消息来说很好?可读性?

提问于
用户回答回答于

JUnit 版本4.4(引入它)的版本注释说明了四个优点:

  • 更具可读性和可键入性:这种语法允许您根据主语,动词,宾语(assert“x is 3”)而不是assertEquals,它使用动词,宾语,主语(断言“等于3 x”)
  • 组合:任何匹配器语句都可以被否定(),合并(或者)或者()),映射到集合(每个),或者在自定义组合中使用(afterFiveSeconds(s)
  • 可读的故障信息。(......)
  • 自定义匹配器。通过自己实现Matcher接口,您可以获得您自己的自定义断言的所有上述优点。
用户回答回答于

对于assertFoo存在与你的意图完全匹配的情况,没有什么大的优势。在这些情况下,他们的表现几乎相同。

但是当你来检查更复杂的东西时,这个优势就变得更加明显:

assertTrue(foo.contains("someValue") && foo.contains("anotherValue"));

assertThat(foo, hasItems("someValue", "anotherValue"));

我们可以讨论其中哪一个更容易阅读,但一旦断言失败,您将从中得到一个很好的错误信息assertThat,但是只有极少量的信息assertTrue

assertThat会告诉你什么是断言,你取而代之。assertTrue只会告诉你,你有false你的预期true

扫码关注云+社区