面向测试编程--代码的可测性

背景

这是之前参加的一个工程师交流会上别人分享的一个小议题,做了一些笔记,后面整理资料的时候又从网上搜集了一些做补充,今天分享一下

代码的可测性

测试性不好的代码特征

缺陷1: 构造函数做了实际工作

• 构造函数或域声明中出现new字眼
• 构造函数或域声明中调用静态方法
• 构造函数做了分配域字段之外的事情
• 构造函数中,对象初始化工作没有完成彻底(小心初始化方法)
• 构造函数中,出现了控制流(基于条件或循环的逻辑)
• 在构造函数内构造复杂的对象图,而不是使用工厂(factory)模式或构造器(builder)模式
• 增加或使用初始化块

缺陷2: 滥用协作类

• 引入了对象,却不直接使用(而是用于通往其它对象)
• 不遵守迪米特法则:对象图中,方法引用链包含了多个下标点(.)
• 可疑命名:如context,environment,principal,container或manager

缺陷3: 脆弱的全局变量&单例(Singleton)

• 增加或使用单例
• 增加或使用静态域字段或静态方法
• 增加或使用静态初始化块
• 增加或使用寄存器
• 增加或使用服务定位器

缺陷4: 类做事太多

• 总结该类的作用时,得使用以及之类的描述语
• 团队新成员很难读懂和快速接手该类
• 该类的某些域字段只用到部分方法中
• 该类的某些静态方法仅针对参数操作

构造函数

一个常见的测试性不好的地方就是在构造函数中做了实际工作,在构造函数中执行功能相当于让对象实例化难上加难,或者说给对象模拟增加困难

例1: 构造函数或域声明中出现了new字眼