有很多书或文章都在探讨如何编写好软件，但很少有讨论如何编写容易测试的软件，幸好，如果遵从创建良好软件的一般原则，即分离问题、避免复制、隐藏信息，并创建结构良好、易于理解和修改的软件，那么就能编写出容易调试的软件。良好的设计与测试并无冲突。
代码的每一块都建立在一个无数假设的平台上——某些条件必须是正确的才能让运行结果符合预期，往往缺陷的出现是因为某些假设是不成立的或者是错误的。避免做出这些假设是不可能的也是没意义的，我们不仅可以验证它们，也可以通过断言来自动验证。
断言长什么样？在Java里有两种格式，一种简单的格式：assert <condition>; 还有一种格式包含一条信息，若断言失败则显示信息：assert <condition>: <message>; 无论使用哪种格式，无论何时被执行，断言都要计算条件，如果条件为真，则什么也不做，如果条件为假则抛出AssertionError的异常，此时程序立即退出。
进行单元测试的时候是否需要断言？
断言和单元测试时解决相关但不同问题的方法，单元测试不能检测没有在测试用例中被引用的缺陷，而任何时候都可以使用断言来检测缺陷，无论是在测试中还是其他什么场合。
断言使得程序出现错误时，不需要我们主动去寻找缺陷，而是让程序自己通知出错并且告诉我们这个缺陷的相关信息。
有没有一些普遍的规律帮助确定我们该断言哪一类的问题呢？
先决条件：对于方法来说，先决条件是那些在方法被调用之前就必须满足的条件，它保证方法可以按预期运行。
后置条件：对于方法来说，后置条件是那些方法被调用之后所要保持的条件。
不变量：对象的不变量是那些只要在方法被调用之前它的先决条件被满足就始终为真的数据。
实现一个类时只要总按照上面三条编写断言，软件就会自动检测大量可能存在的各类缺陷。
既然断言的益处这么多，为何我们在有时候还要选择关闭断言功能呢？因为效率和健壮性。
断言的求值花费时间，对于程序的功能也没有任何贡献，甚至有可能它会影响到程序的性能。而断言的失败会让软件随意退出并弹出一个简短且没帮助的信息，这回导致程序的健壮性。
软件在产品阶段应该是健壮的，但调试的时候应该是脆弱的。
想象一下我们编写了一个函数，它包含一个字符串类型的参数，如果这个字符串全部是大写就返回真，否则返回假，以下是Java中一种可能的实现方式：
| public static boolean allUpper(String s) { CharacterIterator i = new StringCharacterIterator(s); for(char c = i.first(); c != CharacterIterator.DONE; c = i.Next()) if(Character.isLowerCase(c)) return false; return true; } |
这是一个十分合理的函数——但是由于某种原因我们将null作为参数传递给这个函数，我们的软件将会崩溃。为避免这种情况发生，一些开发者可能会在代码开头添加一些代码：
| if(s == null) return false; |
现在程序不会崩溃了，但是当程序调用函数的时候传进一个空字符串是什么意思呢？有可能任何这样做的代码都包含缺陷，但现在我们将它掩盖过去了。
断言给我们提供了一个非常简单的解决方法，无论在哪里写防错性代码，都要确保使用断言保护这段代码：
| assert s != null: "Null string passed to allUpper"; if (s == null) return false; |
