assertThat, assertEquals, assertTrue

昨天晚上是AgileChina 2011的Open House活动，我是Coding环节的志愿者。Coding环节主要是想让参会的开发人员体验一下结对编程、测试驱动开发以及重构的过程。我们准备了四个不同类型的编程题目，公司会有八九位同事和参会的同行一起来体验这个过程：

1. Time Sheet
2. 超市结账
3. 源代码行数统计
4. 21点游戏

总体说来，活动还是挺成功的，只是出现两个小插曲：

1、公司为了这次活动新买的键盘和鼠标，可是敲起来太没手感了，键盘上的键都是平平的。有位参与者可能是不太熟悉键盘总是把回车敲错成斜杠很多次。

2、系统的锁屏快捷键与IDE的格式化代码快捷键相冲突，导致我两次敲错了锁屏了，而且机器也不是我的，要找其他同事来帮忙输入密码，汗死。

在最后一轮Pair当中，一位同学问到：为什么不使用assertEquals呢？我看到你们都是在用assertThat，好像不怎么提倡用assertEquals和assertTrue等。

当时因为活动快结束了，我们要去拍合照，所以简单的回答了一下。这里再详细回答一下这个问题。

我们想从断言里获得什么

对于测试里的断言，我们想从中获得什么呢？测试失败后仅仅显示一个红色条并不是我们想要的，除此之外我们还想从测试中获得一些信息：

1、哪里的测试失败了，有代码行么？这个所有的断言都能提供这个功能

2、测试为什么失败 这个就很难界定了。大部分断言都能提供类似这种功能：

期望的结果 vs 实际的结果

但是不同的断言提供的信息却不尽相同。还有一些问题，用简单的相等之类的断言是很难比较的。而且，断言还有一个非常重要的作用：文档。也就是，当你阅读测试代码时，看到断言你就像是看到了所有的期望。而且非常明了的期望。

实际的例子

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

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