为什么我应该使用Hamcrest-Matcher和assertThat()而不是传统的assertXXX()-Methods
为什么我应该使用Hamcrest-Matcher和assertThat()而不是传统的assertXXX()-Methods
提问于 2009-11-09 21:56:37
当我查看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 )有多大的优势。
如果结构变得更复杂，这可能对消息来说很好，但你看到了更多的好处吗？可读性？
回答 4
Stack Overflow用户
发布于 2009-11-09 22:02:19
对于那些存在与您的意图完全匹配的assertFoo的情况，并没有太大的优势。在这些情况下，它们的行为几乎是相同的。
但是，当您遇到比较复杂的检查时，优势就会变得更加明显：
val foo = List.of("someValue");
assertTrue(foo.contains("someValue") && foo.contains("anotherValue"));Expected: is <true>
but: was <false>与
val foo = List.of("someValue");
assertThat(foo, containsInAnyOrder("someValue", "anotherValue"));Expected: iterable with items ["someValue", "anotherValue"] in any order
but: no item matches: "anotherValue" in ["someValue"]人们可以讨论其中哪一个更容易阅读，但是一旦断言失败，您将从assertThat得到一条很好的错误消息，但从assertTrue得到的信息却非常少。
Stack Overflow用户
发布于 2012-02-28 13:40:35
一个非常基本的理由是，很难弄乱新的语法。
假设一个特定值foo在测试后应该是1。
assertEqual(1, foo);-或者--
assertThat(foo, is(1));使用第一种方法，很容易忘记正确的顺序，并向后键入它。然后，不是说测试失败是因为它预期为1而得到2，而是该消息是反向的。当测试通过时不是问题，但当测试失败时会导致混乱。
在第二个版本中，几乎不可能犯这个错误。
Stack Overflow用户
发布于 2015-02-01 07:45:23
assertThat(frodo.getName()).isEqualTo("Frodo");接近于自然语言。
更容易阅读，更容易分析代码。程序员花更多的时间来分析代码，而不是写新的代码。因此，如果代码易于分析，那么开发人员应该更有效率。
附言:代码应该是写得很好的书。自我记录的代码。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/1701113
复制相关文章
相似问题