当我查看 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 )。
如果结构变得更复杂，那么消息可能会很好，但您是否看到更多优势？可读性？
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.
4.4 版的 JUnit发行说明（它被引入的地方）陈述了四个优点：
- 更具可读性和可键入性：此语法允许您根据主语、动词、宾语（断言“x 为 3”）而不是assertEquals来思考，后者使用动词、宾语、主语（断言“等于 3 x”）
- 组合：任何匹配器语句 s 都可以被否定（not(s)），组合（any(s).or(t)），映射到集合（each(s)），或用于自定义组合（afterFiveSeconds(s) )
- 可读的失败消息。(...)
- 自定义匹配器。通过自己实现Matcher接口，您可以为自己的自定义断言获得上述所有好处。
来自创建新语法的人的更详细的论证：这里。
基本上是为了增加代码的可读性。
除了 hamcrest 你还可以使用fest assertions。与 hamcrest 相比，它们有一些优势，例如：
assertEquals(123, actual); // reads "assert equals 123 is actual"vsassertThat(actual).isEqualTo(123); // reads "assert that actual is equal to 123")import static org.fest.assertions.api.Assertions.*;
// common assertions
assertThat(yoda).isInstanceOf(Jedi.class);
assertThat(frodo.getName()).isEqualTo("Frodo");
assertThat(frodo).isNotEqualTo(sauron);
assertThat(frodo).isIn(fellowshipOfTheRing);
assertThat(sauron).isNotIn(fellowshipOfTheRing);
// String specific assertions
assertThat(frodo.getName()).startsWith("Fro").endsWith("do")
.isEqualToIgnoringCase("frodo");
// collection specific assertions
assertThat(fellowshipOfTheRing).hasSize(9)
.contains(frodo, sam)
.excludes(sauron);
// map specific assertions (One ring and elves ring bearers initialized before)
assertThat(ringBearers).hasSize(4)
.includes(entry(Ring.oneRing, frodo), entry(Ring.nenya, galadriel))
.excludes(entry(Ring.oneRing, aragorn));
Fest 不再活动，请改用AssertJ。
一个非常基本的理由是很难弄乱新语法。
假设特定值 foo 在测试后应该为 1。
assertEqual(1, foo);
- 或者 -
assertThat(foo, is(1));
使用第一种方法，很容易忘记正确的顺序，然后倒着输入。然后不是说测试失败是因为它期望 1 并得到 2，而是消息是倒退的。测试通过时不是问题，但测试失败时可能会导致混乱。
使用第二个版本，几乎不可能犯这个错误。
例子：
assertThat(5 , allOf(greaterThan(1),lessThan(3)));
// java.lang.AssertionError:
// Expected: (a value greater than <1> and a value less than <3>)
// got: <5>
assertTrue("Number not between 1 and 3!", 1 < 5 && 5 < 3);
// java.lang.AssertionError: Number not between 1 and 3!
顺便说一句：你也可以在 assertXXX 中写 Text ......
assertThat(frodo.getName()).isEqualTo("Frodo");
接近自然语言。
更容易阅读，更容易分析代码。程序员花更多的时间来分析代码而不是编写新代码。因此，如果代码易于分析，那么开发人员应该更有效率。
PS Code 应该是一本写得很好的书。自我记录的代码。
与 assertEquals 相比，assertThat 有一些优势 -
1) 更具可读性
2) 有关失败的更多信息
3) 编译时错误 - 而不是运行时错误
4) 编写测试条件的灵活性
5) 可移植 - 如果您使用的是 hamcrest - 您可以使用 jUnit或 TestNG 作为底层框架。