断言的副作用

由于程序员的问题，断言的使用可能会带来副作用 ，例如：

boolean isEnable=false

//...

assert isEnable=true

这个断言坦态烂的副作用是让漏因为它修改了程序中变量的值并且未抛出错误，这样的错误如果不细心的检查是很难发现的。但是同时我们可以根据以上的闭坦副作用得到一个有用的特性，根据它来测试断言是否打开。

public class AssertExampleTwo{

public static void main(String args[]){

boolean isEnable=false

//...

assert isEnable=true

if(isEnable==false){

throw new RuntimeException(Assertion should be enabled!)

}

}

}

大家都知道，在软件测试特别是在单元测试时,必用的一个功能就是“断言”（Assert)，可能有些人觉得不就一个Assert语句，没啥花头，也有很多人用起来也是懵懵懂懂，认为只要是Assert开头的方法，拿过来就用。一个偶然的机会跟人聊到此功能，觉得还是有必要在此整理一下如何使用以及对“断言”的理解。希望可以帮助大家对此有一个系统的理解，也趁机聊聊“断言”发展一路过来的心路历程。

首先稍微介绍一下断言相关知识，对于有经验的程序员请移步到下面的“断言”进化史部分。

在单元测试时，程序员预计在程序运行到某个节点位置，需要判断某些逻辑条件必须满足，这样下面的一些业务逻辑才可以进行下去，如果不满足，程序就会"报错"甚至是"崩溃"。比如说，一段程序是负责“转账”，在真正开始转账 *** 作前首先需要“断言”这个账户是一个“合法”的账户，比如账户不是 null 。当出现些状况时，程序开发人员就可以在第一时间知道这个问题，可以去 debug 除错，而非等到交付给用户后才发现问题。其实这个功能是TDD (Test Driven Develop)的基石之一。

一开始的一些单元测试框架（比如JUnit）提供的断言语句，这样在程序某个地方确保某个逻辑关系肯定返回是true,如果不是true,这个单元测试就是没有测试通过。如下就是一个例子,如果程序运行到此行时返回false程序就会抛出一个错误（如下图一）并停止运行，开发人员可以去检查下为什么出现此问题。非常的简单粗爆。

上面这种断言除了简单之外，是有一个问题，就是当断言被触发时显示出来的错误消息不是很友好。如上图一，只是知道出错了，但是并没有太多有用的信息，比如最好是能显示出x与y的值来，这样好更快的理解为啥出错。后来，支持断言的单元测试框架升级版本出现了，它们提供了一系列的高级”断言“语句，添加了一些更加友好的程序接口，同时还提供比较亲民的错误消息，比如下面的例子使用了两个单独的断言语句。

执行的结果如下图二，你可以看到这个错误结果相对于上面“石器时代”已经包括了不少有用的信息，比如除了知道断言失败外还显示了 期望的值 以及 实际值 。

但是上面这种方式有一个弊端，就是需要大量的预置断言方法（比如判断相等一个方法，判断不相等一个方法等），去支持各种场景。接下来又出现了新的解决方案，其中的明星就是 Hamcrest (其实这个词是使用一种叫做 angram 的文字游戏，即把一个原来单词中的字母顺序改变，这个Hamcrest就是从Matchers的变形)框架。是使用一种 assertThat 组合上 Matcher 来使用。

这个有多个好处，

上面说了这么多，是不是感觉平时经常使用的一个看似简简单单的Assert还有不少的东西可以深挖一下滴。这个只是抛砖引玉，如果大家还有什么点子或建议请使用下面的方式。

---