我们的这个单测框架包括三个部分，第一部分是覆盖率，包括全量覆盖率和增量覆盖率统计，以及根据增量覆盖率设计的代码准入限制，第二部分是报告，包括所有组件的覆盖率的总体报告和每个组件的覆盖率趋势图，第三部分是推广功能，包括低覆盖率组件的每日提醒和组件周覆盖率提升的排名，提醒和激励大家去补全单测。
覆盖率方面
- 1，首先我们的项目已经进行了组件化，每个组件包含一个module，并且都用gitlab进行管理，所以单测框架是针对每个组件
- 2，对于每个组件，单测框架提供了全量覆盖率统计，和增量覆盖率统计，全量覆盖率是利用jacoco插件进行统计，增量覆盖率是利用一个diff-cover的库，针对jacoco生成的统计结果，筛选出增量代码，进行增量覆盖率统计。全量覆盖率和增量覆盖率统计都利用gradle task 进行封装，本地只要运行对应的task，就可以对组件的覆盖率进行输出。
4，为了形成一套闭环的单测框架，我们利用了gitlab ci对覆盖率进行管理，gitlab ci 就是在服务器电脑电脑上安装一个runner，然后每个组件项目增加一个.gitlab.yml的文件，在.gitlab.yml文件中执行对应的task，服务器电脑上的runner就会下载对应项目，然后在服务器本地去执行对应的task。
5，然后我们全量覆盖率和增量覆盖率什么时机去执行呢，对于全量覆盖率，我们配置的执行时机是web，就是在gitlab ci 界面，点击它里面的一个run pipeline 按钮时执行，执行完成后，在流水线页面，显示对应的覆盖率，这样对于每个组件，我们不用下载它的源码，就可以直接获取它全量覆盖率。 6，对于增量覆盖率，我们配置的执行时机是在代码合并阶段，当代码合并时，执行增量覆盖率task，判断是否小于我们设定的阈值，如果小于，流水线失败，合并按钮为灰色，不能合并，保证准入代码质量。
7，但是对于组件的负责人，他有权限关闭流水线必须成功才能合并代码的设置，从而绕过增量覆盖率检测，对于这种情况我门做了一个增加覆盖率检测强化
这个的话时，借助我们代码review的一个工具，在我们提了组件mr时，会有代码review，只有review人员评论了审核通过，才会给出这个组件的打包密码，这里要说明的是，就是我们组件修改代码之后，都是通过打包成aar之后，才可以集成到主项目中去，我们就利用这个review阶段，当review人员评论了审核通过之后，我们再去判断这个mr的增量覆率是否达标，如果达标，就进行利用金山协作的群机器人@对应人员，进行提示，让其不全单测之后，才可以给出组件的打包密码。
8，对于全量覆盖率和增量覆盖率的执行结果，我们除了可以在gitlab上面查看以外，我们还会通过我们的金山协作软件的群机器人进行通知，并at对应人员，进行相应处理，形成闭环。
报告方面， 包含了两份报告， 作用： 1，一份是所有组件覆盖报告，包括所有组件平均覆盖率，和一张每个组件的覆盖率表格，通过这个报告可以了解项目整体的覆盖率情况， 2，另外一份是单个组件覆盖率趋势图，横坐标就是mr节点，纵坐标就是mr节点对应的组件覆盖率，通过这个趋势图可以了解 组件的覆盖率趋势，对于趋势下降的节点，组件负责人可以找对应mr人员补齐对应mr单测。
对于报告数据的存储方面， 我们开始是使用一个excel表格去存储数据。数据包括两个方面， 第一个是每个组件的覆盖率初始数据，我们使用gitlab父子流水线，利用一个父项目驱动所有组件执行全量覆盖率task，将覆盖率结果，记录到excel表格。 第二个是后续的mr数据，每次mr合并之后也会执行全量覆盖率的task，得到合并之后的全量覆盖率，再次向excel表格记录一条数据，包括mr合并信息。
对于报告展示， 我们是利用的两个h5文件，一个all coverage对应所有组件的覆盖率报告，一个trend coverage对应组件的覆盖率趋势图，这两个文件连同刚才说的excel文件都是放置在一个unix服务器上，这样，我们通过ip地址就可以访问他们，
对于allcoverage，我们是根据组件名称对excel中的数据进行分组，统计出每个组件的最新一条覆盖率记录，绘制成一张组件覆盖率表格，然后统计所有组件覆盖行数和总行数，绘制一个所有组件平均覆盖率表格。
对于trendcoverage，我们会在它对应的url后面追加一个组件名称的参数，然后通过组件名称去Excel表格中，筛选出对应组件对应的提交记录，然后绘制一张组件覆盖率趋势折线图。横坐标就是mr提交信息，纵坐标就是对应的覆盖率。
这是我们报告开始的一个展示方式。 后面我们又调研了一个redash的统计平台，进行私有化，然后将数据的存储和展示迁移到了这个平台。excel表格对应这个平台的一个数据库，展示的话，manggodb sql 语句查询对应数据，然后利用这个平台的图表进行展示。查询的逻辑和我们刚才说的差不多。
推广方面 包括一个低覆盖率组件的每日提醒和组件周覆盖率提升的排名 每日提醒是由gitlab ci 定时任务，每天统计出当前覆盖率目标之下的组件，做成一个列表，然后通过金山协作群机器人发送通知，并且at对应组件负责任，及时补全单测，并且还附带了一些激励的语句，比如说覆盖率为0的组件，我们可以说，千里之行始于足下，破零行动起来，对于快要达到目标的组件，我们可以说临门一脚了，冲一下。
周覆盖率提升排名，也是通过gitlab ci 定时任务，每周五统计出覆盖率提升最多的5个组件，然后通过金山协作群机器人发送通知，并且at所有人，对这5个组件的负责人是一个表扬作用，对其他人是一个激励作用嘛
然后这就是我们单测框架的一个整体结构。 其实我们单测框架做的东西还有很多，比如说一个组件多个module，怎么统计多个module的覆盖率，单测流水线失败怎么检测，不需要单测的的文件怎么排除，placeholder怎么自动化处理，等等。还是做了比较多的东西的
