Java, Only Java!

• 3.1 构建单元测试
• 3.2 JUnit的各种断言
• 3.3 JUnit框架

总览

这是本相对简单的书，书中采用的JUnit的版本也是旧的，但是在新的JUnit4下稍做修改依然可以运行。重要的是通过这本书了解JUnit在Java的单元测试中是如何使用的。

第2章 首个单元测试

计划你的测试：测试不是无中生有的，也不是意想天开的。是根据需要一点点添加的，帮助自己尽早地发现思考上的误区。参看这章给出的例子，原来理所当然正确的，结果不一定是正确的。

第3章 使用JUnit编写测试

3.1 构建单元测试

测试代码必须要做的几件事情：

• 准备测试的条件（创建对象、分配资源等等）
• 调用测试的方法
• 验证测试方法的行为与期望是否相符
• 测试结束后清理现场（释放资源等等）

  3.2 JUnit的各种断言

  断言：JUnit提供的辅助函数，帮助你确认被测试函数是否正确运行。

后面还介绍了（3.5 JUnit的自定义断言）

3.3 JUnit框架

这章是基于JUnit3.x写的，建议了解就可以了，因为JUnit4的变化较大，使用也更方便直观，因此直接参考JUnit4的帮助。

4. 测试什么？

6个需要测试的地方（Right-BICEP）：

• Right：结果是否正确（Right）；
• B：边界（Boundary）条件是否正确(CORRECT)；参考第5章
• I：能否检查反向（Inverse）关系；
• C：进行交叉检查（Cross-Check）的其他手段；
• E：强制错误（Error）条件发生；使用Mock对象实现，参考第6章
• P：满足性能（Performance）的要求。

测试内容较多时，可以使用测试数据文件进行准备。但是使用文件后就没有测试代码看起来那么直观了，因此除非测试内容非常复杂，否则没有必要采用这样的方式。并且如果测试文件出现错误（作者书中就出现了数据错误），还会导致测试不通过，增加了维护的成本。

5.CORRECT（正确的）边界条件

• 一致性（Conformance）：值是否符合预期的格式；
• 有序性（Ordering）：一组值是否符合对排序的要求（有序性、无序性）；
• 区间性（Range）：值是否在合理取值范围内（在最小值与最大值之间）；
• 引用（Reference）-耦合性：代码是否引用了不受代码本身直接控制的外部因素；
• 存在性（Existence）：值是否存在（例如：非NULL，非零，包含于某个集合等等）
• 基数性（Cardinality）：是否恰好有足够的值；（也称为集合的势，即集合里面包含的元素个数）
• 时间性（Time）-绝对时间和相对时间：所有的事情是否按照顺序发生？是否在正确的时间发生？是否及时发生？

6.使用Mock对象

Mock对象解决的问题：

• 真实对象具有不可确定的行为（如：股票行情）；
• 真实对象很难被创建；
• 真实对象的某些行为很难被触发（如：网络错误）；
• 真实对象令程序的运行速度很慢；
• 真实对象有用户界面或者就是用户界面；
• 真实对象需要被询问它是如何被调用的（如：验证某个回调函数是否被调用）；
• 真实对象实际上不存在（如：其他开发小组的接口、或者某个没有的硬件产品）。

Mock对象解决的步骤：

• 使用一个接口来描述这个对象；
• 为产品代码实现这个接口；
• 以测试为目的，在Mock对象中实现这个接口。

注：这里的Mock不是网上已经形成框架的Mock工具，是Mock的实现原理。作者推荐的Mock工具是EasyMock。其他的Mock工具可以参考《[使用Mock进行单元测试]》(https://blog.csdn.net/u011393781/article/details/52669772)

7. 好的测试所具有的品质(A-TRIP)

• 自动化（Automatic）：自动化地调用测试和检查结果；常用的持续集成工具
• 彻底的（Thorough）：测试了所有需求关注的情况；常用的代码覆盖工具
• 可重复（Repeatable）：每个测试应该独立于其他所有的测试，还必须独立于环境，从而可以重复地执行，并且产生相同的结果。
• 独立的（Independent）：确保一个函数只针对一样测试，并且这个测试不依赖于其他测试。
• 专业的（Professional）：测试代码应该与产品代码的编码风格和编写质量相同

如何确保测试代码是正确的呢？

• 对产品代码中的Bug进行修改的时候也改进测试代码；（因为这个Bug是测试代码没有发现的）
• 在产品代码中引入Bug来验证测试代码的正确性。（确保可能会发生的错误被测试代码捕捉到了）

8. 在项目中进行测试

• 把测试代码与产品代码放在一个目录下；
• 与别人共享代码的时候，需要确保你的代码可以通过所有测试；
• 测试的时间点：
  • 编写新的函数；
  • 修正Bug；
  • 每次成功编译之后；
  • 每次对版本控制的提交；
  • 持续不断地由专门的机器来运行完整的构建和测试。
• 测试别人的项目代码：其实就是维护别人的项目绝对是个大问题，同时也是个必须面对的问题。需要理性的态度（不批评别人的代码）、冷静的手段（不随便修改别人的代码）、持久的耐心（先从测试代码开始，慢慢重构项目代码，使之重新回到健康状态）、真正的智慧（知道什么样的项目应该达到什么样的目标，不执着于重构成一个完美的状态，也不简单放弃随之自生自灭。）
• 测试与评审：三个臭皮匠顶个诸葛亮，放下自我的执着，接纳各种不同的意见，才能做出令自己满意的项目。

9. 设计话题

• 面向测试的设计：不方便测试的设计不是好的设计；说明设计过于僵化或者臃肿，需要简化或者修改使之更利用未来的扩展和维护。
• 面向测试的重构：不方便测试的代码不是好的代码；说明业务混杂在一起，无法实现一个函数只针对一样测试，需要修改设计使业务分离。
• 测试类的不变性：就是对类的断言必须为真。
  • 有序性。例如：sorted list类的不变性就是无论发生什么，结果都应该是有序的。
  • 结构化。例如：订单系统中每个条目必须属于一个订单，一个订单拥有一个或多个条目。
  • 数学不变性。例如：银行账号的的借贷必须平衡。
  • 数据一致性。例如：商品总数=库存数+销售数。
• 测试驱动的设计。使你作为产品代码的用户在编码，而不是产品开发者在编码，开发结果更能反应用户的需求。
• 测试无效的参数。当你作为产品代码的用户时，你才能真正确定哪些责任应该你来承担，而哪些是不需要的。例如：无效的参数应该由哪个函数来承担检查责任呢？