单元测试之道-深入理解JUnit
这本书是从小工到专家系列之一。这个系列有一本总纲性的《程序员修炼之道-从小工到专家》以及《版本控制之道》《单元测试之道》《项目自动化之道》三本具体软件工程技术指导书。软件工程的重要性不必多言，数据结构和算法的重要性也日渐显露，所以此后学习一定要围绕这两方面，编程也要向这两方面靠拢。
不能这样搞测试：风和日丽的一天，一辆车顺利地开过一座桥。我们必须考虑很多的车，很烂的天气。Bug出现的位置常在边界附近（0、1、N）。在定义最小值时，注意0并不是最小值。而是Integer.Min_value这个值。还有为了防止各种数据的溢出错误，一定要注意使用带验证功能的数据结构，例如温度计度数数据结构带有上下区间，不要使用系统自带的基本数据类型。
使用JUnit编写测试的一般步骤：1.准备测试条件：创建对象分配资源2.调用要测试的方法3.验证一致性4.清理各种资源
常见断言：assertEquals注意提示字符串和精度范文，assertNull，assertSame是否引用同一个对象，assertTrue，fail常用在不可能到达的地方，例如捕获异常后。
其他问题：
① 关于setUp和tearDown的调用顺序和次数问题：setUp和tearDown是每一个测试用例的方法都要调用的。
② 注意使用自定义的测试类，这样便于改动基类而不影响其它。
③ DRY原则，即不要重复你自己做过的工作。在修改中我们可以将调用委托给另外的方法，只做少量修改
六个测试部位RIGHT-BICEP：
① Right结果是否正确
② B边界条件是否正确：Conformance一致性：是否和预期的一致，Ordering顺序性，Range区间性：位于合理的最大最小值之间，Reference依赖性，Existence存在性，Cardinatity基数性：恰好有足够的值，Time相对或者绝对的时间性。
③ I反向关联：反向关联可以用来编写反向测试
④ C能用其他手段交叉检查一下结果么
⑤ E强制错误条件发生
⑥ P是否满足性能要求
好的测试的品质：自动化（持续构建和持续集成vs微观）、彻底的（代码覆盖工具nounit和quilt、注意BUG的28定律）、可重复、独立性（一个测试函数应该专注于代码的一个函数，建立函数和测试的对应关系）、专业的（抽取代码和封装这些属性都要用到测试代码中，代码量和测试代码量要基本相当）
关于设计的话题
① 面向设计可以更好地分离关注点：编写内向和害羞的shy code，来满足代码的封装性、正交性和耦合性。我们可以通过代码更容易测试而改善代码设计，同时更简洁易扩展和维护
② 通过定义类不变性来阐明设计意图：测试代码很丑或者难以编写时，说明你的设计需要修改，例如测试任何部分都需要系统整体运行。
③ 通过TDD来改善接口：通过编写测试，把自己作为代码使用者，而非代码实现者。
④ 确立和局部化验证责任
运行测试的方法：使用javacom.abc.test.TestA testAdd testSub这条CMD命令测试了TestA类下的两个测试方法。
测试的一般原则：测试任何可能失败的地方、测试任何已经失败的地方、任何新加代码，在被证明前，都可能有问题、至少编写和代码一样多的测试代码、针对每次编译都做局部测试、嵌入代码前做全局测试。
修改BUG步骤：1验证BUG、2.编写测试代码证明BUG、3修正BUG、4验证测试成功、5引入BUG证明测试通过
一些其他思考:
a) 相同的问题在其它地方么：不论是编程、写文章、做事都是这样，别人指出了一个缺点，我们必须想其他方面的问题。
b) 自定义测试骨架：自定义测试骨架，可以把自己的测试架构在可定制的基础上，方便之后操作。
c) 积累的关键在于反思与回顾，不在于存储的积累。不要只做不想
一些资源：Ant跨平台构建工具、Easy-Mock（测试中使用Mock对象的简单方法）、Nounit（图形化向你展示你项目中多少方法被测试和测试程度）、Quilt（代码覆盖）。
关于JUnit4的改进：不用继承TestCase类。测试方法不用必须加Test前缀了。增加了BeforeClass和AfterClass用于一些类规模的资源初始化和清除工作。使用@可以定义所有方法，不用拘泥固定方法名。可以测试异常，取代原来的fail方法。如@Test(expected=ArithmeticException.class)。可以简单的进行性能测试，超时参数可以简单测试。@Test(timeout=500)。为了JUnit4的测试代码在JUnit3环境下运行，可以使用JUnit4TestAdapter来封装。但方法存疑
参考文献
1. JUnit工具使用
2. Eclipse下用Ant运行JUnit
3. 理解JUnit