初识单元测试（一）——概况

文章目录

1. 什么是单元测试
2. 单元测试地目的
3. 单元测试的好处
4. 单元测试的基本原则
5. Mock的由来及应用场景
6. Mock的本质
7. Mock的实现方式

1.什么是单元测试

计算机世界里的软件产品通常是由模块组合而成，模块又可以分成诸多子模块。比如淘宝系统由搜索模块、商品模块、交易模块等组成，而交易模块又分成下单模块、支付模块等子模块，如此细分下去，最终的子模块是由不可再分的程序单元组成的。对这些程序单元的测试，即称为单元测试（Unit Testing，简称单侧）。

2.单元测试地目的

在集成测试和功能测试之前对软件中的可测试单元进行逐一检查和验证。

3.单元测试的好处

1. 提升软件质量
   优质的单元测试可以保障开发质量和程序的鲁棒性。软件工程界的一条金科玉律：越早发现的缺陷，其修复成本越低。一流的测试能发现未发生的故障；二流的测试能快速定位故障的发生点；三流的测试则疲于奔命，一直跟在故障后面进行功能回归。
2. 促进代码优化
   促使开发工程师不断重新审视自己的代码，白盒地去思考代码逻辑，更好地对代码进行设计，甚至想方设法地优化测试用例执行效率。这过程会促使我们不断地优化自己的代码，有时候这种优化的冲动是潜意识的。
3. 提升研发效率
   从表面上看，写单侧表面上占用了项目研发时间，但在后续的联调、集成、回归测试阶段中，单元测试覆盖率高的代码通常缺陷少、问题易于修复，有助于提升整体研发效率。
4. 增加重构自信
   代码重构往往牵一发而动全身。当修改底层数据结构时，上层服务经常会受到影响。但在单元测试保障的前提下，重构代码时自然地多了一分信心。

4.单元测试基本原则

宏观上，单测要符合AIR原则；微观上，单测的代码层面要符合BCDE原则。

1. AIR即空气，当业务代码在线上运行时，可能感觉不到测试用例的存在和价值，但在代码质量的保障上，却是至关重要。

• A：Automatic（自动化）：
  单测的执行过程应该是全自动的，如果单测的输出结果需要人工介入检查，那一定是不合格的。另外单测中不允许使用System.out来进行人工验证，而必须使用断言来验证。
• B：Independent（独立性）：
  为了保证单测稳定可靠便于维护，需保证其独立性。用例之间不允许互相调用，也不允许出现执行次序的先后依赖。（主流测试框架中，JUnit的用例执行顺序是无序的，而TestNG支持测试用例的顺序执行）
• R：Repeatable（可重复）
  单测是可以重复执行的，不能受到外界环境的影响。

2. BCDE原则，为了保证被测模块的交付质量需符合的原则。

• B：Border（边界值测试）：
  包括循环边界、特殊取值、特殊时间地点、数据顺序等。
• C：Correct（正确的输入）：
  正确的输入，并得到预期的结果
• D：Design（与设计文档相结合）
• E：Error（目标是证明程序有错）：
  单测的目标是证明程序有错，而不是程序无错。为了发现代码中潜在的错误，我们需要在编写测试用例时有一些强制的错误输入（异常流程、非法数据等）来得到预期的错误结果。

注意：

1. 写单测时需保证测试粒度足够小，这样有助于精确定位问题。
2. 单测用例默认是方法级别的
3. 单测不负责检查跨类或者跨系统的交互逻辑，那是集成测试需要覆盖的范围

5.Mock的由来及应用场景

由于单元测试只是系统集成测试前的小模块测试，有些因素往往是不具备的，因此需要进行Mock，例如：

• 功能因素。比如被测试方法内部调用的功能不可用。
• 时间因素。比如双十一还没到来，与此相关的功能点。
• 环境因素。政策环境，如支付宝类新功能；多端环境，如PC、手机等。
• 数据因素。线下数据样本过小，难以覆盖各种线上真实场景。
• 其他因素。为了简化测试编写，开发者也可以将一些复杂的依赖采用Mock方式实现。

6.Mock的本质

是让我们写出更加稳定的单元测试，隔离上述因素对单测的影响，使结果变得可预测，做到真正的“单元”测试。

7.Mock的实现方式

最简单的是硬编码，更为优雅的方式是使用配置文件，最佳方式是使用相应的Mock框架，例如JMockit、EasyMock、JMock、Mockito等。