欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  Java

assertThat, assertEquals, assertTrue

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

Time Sheet

超市结账

源代码行数统计

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));

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

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

好,这就是问题所在,如果上面两个断言都失败了,第一个断言的失败信息将是:

期望结果中包含expected….

但是实际上…这里会把findAll返回的所有user都打印出来

而第二个断言呢?是这样的:

期望为true,实际上为false

请问哪一个更靠谱一点?显然第一个断言的失败信息更利于我们寻找问题。

对于文档化,我们再来看这么一个要求:断言返回的用户列表里不包含给定的用户:

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

是不是很清晰明了,读这个断言你不会感觉到你是在读代码,就好像在读Spec。如果用其他的断言:

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

都没有前一个更好的文档化。

当然,对于一些API返回的就是true或false的,或者返回的就是个单值的,你也可以用其他的断言,没有多大问题。比如这个:

   1: assertEquals(userDAO.findBy(id), expected);

啊,什么?你说我用错了,为什么啊。查查参数说明,发现原来期望的值应该放到第一个参数,而实际值应该放到第二个参数。好无奈啊,我记忆力不好,总是会弄错这些,幸好我们有了assertThat:

   1: assertThat(userDAO.findBy(id), is(expected));

你还会弄错么?

以上就是assertThat, assertEquals, assertTrue的内容,更多相关内容请关注PHP中文网(www.php.cn)!