优秀测试的替身

image.png

100%测试覆盖率不是目标
争议在于：写多少测试？写哪种测试？
双稳态定律：编写测试的最大价值不在于结果，而在于编程过程中的学习。
image.png

影响生产力的因素

**
image.png

测试作为设计工具

image.png

TDD的好处：
image.png

偶发复杂性

寻求优秀

可读的代码才是可维护的代码
结构有助于理解事物
image.png

测试应易于单独运行，而不要有前后顺序的依赖。
image.png
image.png

可靠的测试才是可靠的，几乎不会失败的测试就是无用的废物，也就是说，间歇性的通过或者失败的测试就是在公然的侵害工程师的生产力。
image.png

测试替身：测试工具、集成工具等/stub、fake、mock
image.png

测试替身

好处：隔离被测代码、加速执行测试、让测试变得确定
类型：
image.png

指南：
1.stub管查询，mock管操作
2.准备-执行-断言

可读性

1.基本断言
2.过度断言
image.png
3.用一个或者多个布尔运算来替换位运算
4.测试的每个方法应该尽量在同一个抽象层次内，比如把setup或者init内容放在before或者单独的方法中。
5.一个测试应当只检查一件事并妥善执行，分块心理学
6.用具有表现力名字的本地变量或者倡廉替换魔法数字。
7.将冗长的安装抽取无关细节，放入私有方法中

可维护性

1.消除重复：结构重复、语义重复
2.文件路径可迁移
3.删除建立的临时文件
4.适当使用并发工具加快测试速度
5.用参数化工具简化代码和逻辑

可信赖

1.删掉无用注释
2.注意哪些永不失败的测试用例
3.平台偏见

可测的设计

应当容易和快速地为一段代码编写单元测试

模块化设计

1.SOLID:单一职责、开闭原则、里式替换原则、接口隔离原则、依赖反转。
2.以测试驱动出模块化设计

可测性问题

遇到的障碍主要集中在：访问受限、无法替换实现的某些部分
1.无法实例化某个类：可见性或者静态初始化代码块中对某些坏境变量的依赖
2.无法调用某个方法：private等
3.无法观察到输出
4.无法替换某个协作者
5.无法覆盖某个方法

可测的设计指南

1.尽量避免直接测试private方法，通过public来测试它们
2.很少有程序需要final方法，final的目的是为了确保子类不会覆盖它，在安全上比较难避免因为有反射或字节码，而在性能上并不会带来多大的影响，但却影响可测试性。
这点我觉得需要看情况，用final其实是对后来维护者的一种不信任，在性能上的差异并不会决定我是否使用它。
3.避免static方法？？？小心new？？？这两点我不是很赞同
4.避免在构造函数中包含逻辑—这个是基本的编码规范
5.避免单例？？？在适当的情况下使用无妨，但是很多bug就是对单例的错误使用造成的。遇到过不少。
6.组合由于继承
image.png
7.封装外部库

用其他JVM语言来编写测试

需要学习下Groovy,并简单了解下Spock/TestNG相关的测试框架

Junit

JMockit

image.png
image.png
image.png

@Injectable 也是告诉 JMockit生成一个Mocked对象，但@Injectable只是针对其修饰的实例，而@Mocked是针对其修饰类的所有实例。此外，@Injectable对类的静态方法，构造函数没有影响