最近遇到一个单元测试的问题，本周正好学个了一个SCORE法则，这里正好练练手应用此法则将问题的前因后果分享给大家。
S：背景
代码要有单元测试，检测的标准就是统计代码的单元测试覆盖率，程序员需要达到指定的最低覆盖率要求。
C：冲突，或者叫问题吧
项目结构与代码扫描工具的特殊关系导致需要额外写更多的单元测试，因为目前开发管理部门的代码描述配置的是按JAVA工程来扫描，并不能将多个工程当成一个整体来扫描。
我的一个项目将接口以及实体对象单独成立为一个JAVA工程，整个项目分成两个JAVA工程：
接口以及实体，工程名称为core
业务逻辑以及数据持久化的实现，工程名称为service,依赖上面的core
一般情况下，由于core里面只包含接口以及实体，所以我没有意识到去写单元测试，因为单元测试的价值会比较小，无非就是测试实体是否可以序列化，如果实现了JSR303，那么这些校验的逻辑可能也有点测试的价值。由于我们的service依赖core，在为service写单元测试时，实际上已经调用了接口以及实体，理论上是不需要再为core去写单元测试的。但核心问题时代码扫描工具目前开发管理部门做的还没这么智能，它是以单个JAVA工程来统计单元测试覆盖率的，针对我们的结构如果只在service中写单元测试，那么有效的代码覆盖行只会统计service项目中的，至于调用的core项目中的代码并不包含在其中。而core的这些接口以及实体所占的代码行还是有一定分量的，如果不将这些统计进来那么想达到高的覆盖率还是比较费劲的，除非你有大把的时间去写。
O：选择的方案
实体对象无非就是一些get,set成本的方法，要想测试它们我们可以利用序列化机制，对象序列化成字符串会完成get调用，反过来将字符串序列化成对象会完成set的调用，那如何实现呢？
为每个实体对象，编写单元测试，实例化对象，最后完成序列化与反序列化。
优点：可以精确的控制每个属性的值
缺点：需要编写众多单元测试，时间成本高，且新增加实体类就意味着要编写新的单元测试，删除或者修改也会影响。
利用反射机制，动态计算工程中的实体，自动去完成序列化与反序列化。
延伸阅读
- ssh框架 2016-09-30
- 阿里移动安全 [无线安全]玩转无线电——不安全的蓝牙锁 2017-07-26
- 消息队列NetMQ 原理分析4-Socket、Session、Option和Pipe 2024-03-26
- Selective Search for Object Recognition 论文笔记【图片目标分割】 2017-07-26
- 词向量-LRWE模型-更好地识别反义词同义词 2017-07-26
- 从栈不平衡问题 理解 calling convention 2017-07-26
- php imagemagick 处理 图片剪切、压缩、合并、插入文本、背景色透明 2017-07-26
- Swift实现JSON转Model - HandyJSON使用讲解 2017-07-26
- 阿里移动安全 Android端恶意锁屏勒索应用分析 2017-07-26
- 集合结合数据结构来看看(二) 2017-07-26
学习是年轻人改变自己的最好方式