Junit 断言 assertThat, assertEquals, assertTrue

我们想从断言里获得什么

对于测试里的断言，我们想从中获得什么呢？测试失败后仅仅显示一个红色条并不是我们想要的，除此之外我们还想从测试中获得一些信息：1、哪里的测试失败了，有代码行么？这个所有的断言都能提供这个功能2、测试为什么失败 这个就很难界定了。大部分断言都能提供类似这种功能：期望的结果 vs 实际的结果但是不同的断言提供的信息却不尽相同。还有一些问题，用简单的相等之类的断言是很难比较的。而且，断言还有一个非常重要的作用：文档。也就是，当你阅读测试代码时，看到断言你就像是看到了所有的期望。而且非常明了的期望。

实际的例子

看看assertThat的第二个参数，它接受的是一个Matcher<T>，在org.hamcrest里有非常丰富的Matcher实现。比如现在我们的API返回一个用户对象的列表，我们想断言这个列表里包含我们期望的一个用户，hamcrest里就有hasItem这么一个Matcher：

1: assertThat(userDAO.findAll(), hasItem(expected));

如果用其他断言该怎么做？

1: assertTrue(userDAO.findAll().contains(expected));

好，这就是问题所在，如果上面两个断言都失败了，第一个断言的失败信息将是：期望结果中包含expected….但是实际上…这里会把findAll返回的所有user都打印出来而第二个断言呢？是这样的：期望为true，实际上为false请问哪一个更靠谱一点？显然第一个断言的失败信息更利于我们寻找问题。对于文档化，我们再来看这么一个要求：断言返回的用户列表里不包含给定的用户：是不是很清晰明了，读这个断言你不会感觉到你是在读代码，就好像在读Spec。如果用其他的断言：都没有前一个更好的文档化。当然，对于一些API返回的就是true或false的，或者返回的就是个单值的，你也可以用其他的断言，没有多大问题。比如这个：啊，什么？你说我用错了，为什么啊。查查参数说明，发现原来期望的值应该放到第一个参数，而实际值应该放到第二个参数。好无奈啊，我记忆力不好，总是会弄错这些，幸好我们有了assertThat：你还会弄错么？