【单元测试】基础理论

https://insights.thoughtworks.cn/practical-test-pyramid/

https://developer.aliyun.com/article/792515  Java编程技巧之单元测试用例编写流程

https://developer.51cto.com/article/708764.html  淘系用户平台技术团队单元测试建设

https://martinfowler.com/articles/mocksArentStubs.html

https://www.baeldung.com/mockito-series

 好单元测试的几个要点

摘自阿里巴巴开发规约：

l  单元测试必须遵守AIR原则，单元测试必须具备Automatic(自动化)，Independent(独立性)，Repeatable(可重复)性;

l  单元测试应该是全自动执行的，并且非交互式的。测试用例通常是被定期执行的，执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的单元测试;

l  单元测试要保证测试粒度足够小。单元测试测试粒度足够小，有助于精确定位问题。单测粒度至多是类级别，一般是方法级别;

l  单元测试要遵守BCDE原则，Border，边界值测试，包括循环边界、特殊取值、特殊时间点、数据顺序等;Correct，正确的输入，并得到预期的结果;Design，与设计文档相结合，来编写单元测试;Error，强制错误信息输入(如：非法数据、异常流程、非业务允许输入等)，并得到预期的结果;

l  核心业务、核心应用、核心模块的增量代码要确保单元测试通过;

单元测试编码范式

这里主要以Mockito单元测试框架为模版

l  Mock :通过when().thenReturn/thenAnswer/thenThrow 或者doReturn().when()等mock方式将依赖类方法进行模拟，模拟服务依赖或者中间结果。

l  DO : 调用被测试类方法，执行测试链路。

l  Verify : 校验执行结果正确性，通过Assert校验数据结果准确，通过Verify校验链路执行准确，通过expected=Exception.class校验异常链路。

单测要能报错

有些同学不喜欢用Assert，而喜欢在test case中写个System.out.println，人肉观察一下结果，确定结果是否正确。这种写法根本不是单测，原因是即使当时被测试代码是正确的，后续这些代码还有可能被修改，而一旦这些代码被改错了。println根本不会报错，测试正常通过只会带来虚假的自信心，这种所谓的"单测"连暴露错误的作用都起不到，根本就不应该存在。

单测要有覆盖度（SUT）

IDEA支持覆盖度度量

强度是指单元测试中对结果的验证要全面，覆盖度则是指测试用例本身的设计要覆盖被测试程序(SUT, Sysem Under Test)尽可能多的逻辑。只有覆盖度和强度都比较高才能较好的实现单测的目的。

按照测试理论，SUT的覆盖度分为方法覆盖度，行覆盖度，分支覆盖度和组合分支覆盖度几类。不同的系统对单测覆盖度的要求不尽相同，但这是有底线的。一般来说，程序配套的 单测至少要达到>80%的方法覆盖以及>60%的行覆盖 ，才能起到"看门狗"的作用，也才是有维护价值的单测。

等价类划分可以帮助我们用更少的测试代码写出更高覆盖度的单测。 单元测试是典型的白盒测试 ，等价类的划分以及单元测试的编写最好都由SUT的编写者自己去完成，这样整体效率最高。

测试规则

• FIRST

Fast：快速；测试执行越快越早发现问题

Isolated：独立，每个用例独立，没有依赖，从而可以并行甚至分布式执行；

Repeatable：可重复，每个用例不管执行多少次，执行结果一致，幂等；比如用例跟时间相关，可能结果不幂等。

Self-validation：自验证，测试用例必须告知断言结果，而不是人工判断，比如通过println打印。

Timely：及时，不要拖延

• Right-BICEP

Right: 是否符合测试要求，验证待测试系统是否满足设计要求

Boundary：是否检测了所有边界行为

Inverse：是否需要反向检查，

Cross-checking：交叉检查，通过另一种方法对结果进行检查，比如需求的另一个解决方案

Error: 是否需要检查异常情况；如果异常是需要关注的，则需要覆盖异常路径；

Performance：是否需要检查性能，

• CORRECT

Conformance：运行结果是否符合预期的规则

Ordering：值是否应该有序或无序

Range：结果在给定范围内是否符合预期

Reference：待测系统SUT是否正确引用了所依赖组件DOC

Existence：待测系统是否因关键要素存在性被影响，0-1-N问题

Cardinality：某些数值计算是否超出预期，如下标越界

Time：与时间相关的问题是否需要测试，比如耗时，并发问题

评估单元测试覆盖率