JAVA单元测试指引
1.背景
系统的规模及复杂度与时间及业务的拓展成正比。
随着系统的规模不断变大，各子系统内的业务逻辑的新增，系统的代码总数也在不断的增加。
部分业务在时间的推移上会发生变化引起系统在代码层面上的重构，系统代码在软件工程的生命周期中不断的迭代和变化。
代码的新增以及重构都需要通过严格测试才能部署上线，公司目前对于上线功能采取的多数是黑盒测试，并未使用白盒测试对研发人员编写的代码进行更高的覆盖测试。
而研发人员平时在功能开发完成后进行自测的时候使用的方式也因为个人喜好或各种原因没有形成统一。
因此，系统若能在编译、部署、上线的时候能够对所有功能都进行尽可能全面的白盒测试将会有助于降低系统在升级过程中的故障率，提高系统升级的速度。
若能够通过更全面的测试发现代码中的隐藏缺陷，便能提升代码的健壮性，使系统在长期运行中发生更少的问题。
2.需求
研发人员在功能开发结束之后应当同时提交该功能的单元测试用例代码，并且该单元测试用例代码需要满足以下几点需求：
2.1.功能覆盖
1)每个单元测试代码中需要覆盖该功能的所有输入和输出，并对输出进行校验。
2)最终目标每个系统的所有测试用例代码需要覆盖系统的所有功能。
（存量系统在后续分
阶段补充）
2.2.测试颗粒化
1)单元测试用例只测试小颗粒的功能。
2)一个单元测试用例只涉及到一个被测模块，避免牵扯到太多的模块。
2.3.测试自动化
1)单元测试的输入，输出以及校验全部自动化，不需要人工干预。
2)系统编译的时候需要自动将所有单元测试执行一次，任意单元测试不通过不允予通过发
布。
2.4.持续维护
1)新添加的功能和模块需要添加相对应的单元测试用例。
2)重构或业务逻辑变更涉及到的功能和模块代码变化需要更新相对应的单元测试用例。
3.方案
基于公司在JAVA语言方面多数系统是采用Maven进行构建的现状以及Maven在系统构建的优势，故采用Maven进行系统构建+Junit进行用例测试的方案实现。
研发人员可以借助Cobertura对自己编写的测试用例进行代码覆盖分析，以便对测试代码进行调整和优化。
3.1.Maven
1)Maven不仅仅能构建项目，同时还是一个依赖管理工具，一个项目管理工具，提供中央
仓库帮助我们自动下载构件，也允许我们上传自己开发的jar包供各系统使用，这些都
是自动化的非常方便。
2)Maven提供的免费中央仓库涵盖了非常非常多的开源库，能满足绝大多数系统的使用需
求。
3)Maven对于目录结构有要求，约定优于配置，项目间切换就省去了学习成本。
4)Maven项目对单元测试支持很友好，约定的test目录用来编写单元测试代码，maven
在进行系统编译的时候自动执行test目录里测试用例，一旦出现用例不通过maven自动打包发布。
5)Maven构建的系统默认集成了Junit单元测试工具。
3.2.Junit
1)简单易用的单元测试工具，通过断言校验期望值与实际值的差异。
2)支持图形交互，测试结果简洁明了。
3)提供异常堆栈方便跟踪错误代码。
3.3.JaCoCo
1)简介
JaCoCo是一个开源的覆盖率工具(官网地址：/JaCoCo/ )，它针对的开发语言是java，其使用方法很灵活，可以嵌入到Ant、Maven中；可以作为Eclipse 插件，可以使用其JavaAgent技术监控Java程序等等。
2)覆盖率概况
标示绿色的为行覆盖充分，标红色的为未覆盖的行，黄色菱形的为分支部分覆盖，绿色菱形为分支完全覆盖。
3)JaCoCo的使用方式：
➢Apache Ant方式
Task coverage、Task agent、Task dump、Task merge、Task report、Task instrument
➢命令行方式
使用方式说明：
主要放在JAVA_OPTS中，比如：
由AgentOptions的getVMArgument方法加载，各参数入AgentOptions的对应参数，为后续操作做为输入。
系统在jvm停止的时候会dump覆盖率信息。
➢Apache Maven方式
（1）项目已jar包方式打包，引入junit和jacoco。
（2）Build时执行instrument、report、check。
（3）覆盖率生成到target/jacoco.exec
4.测试覆盖
4.1.代码覆盖度
单元测试中对每个被测逻辑体内的代码覆盖有以下几种方法，其覆盖的程度按照顺序递增。
这里借助一个示例对覆盖方法做一个简单的说明，供各位进行参考。
假定被测逻辑入下图（长方形内为代码语句）：
4.1.1.语句覆盖
语句覆盖是最起码的结构覆盖要求，语句覆盖要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。
对应的用例如下：
4.1.2.分支（判定）覆盖
它要求设计足够多的测试用例，使得程序中每个判定至少有一次为真值，有一次为假值，即：程序中的每个分支至少执行一次。
每个判断的取真、取假至少执行一次。
对应的用例如下：
4.1.3.条件覆盖
条件覆盖要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。
对应的测试用例如下：
4.1.4.分支（判定）-条件覆盖
判定-条件覆盖就是设计足够的测试用例，得使判断中每个条件的所有可能取值至少执行一次，同时每个判断本身所有可能结果也至少执行一次。
对应的测试用例如下：
4.1.
5.条件组合覆盖
要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。
满足“条件组合覆盖”的测试用例是一定满足“判定覆盖”、“条件覆盖”和“判定/条件覆盖”的。
对应的测试用例如下：
4.1.6.路径覆盖
路径覆盖的含义是，选取足够多的测试数据，使程序的每条可能路径都至少执行一次（如果程序图中有环，则要求每个环至少经过一次）。
对应的测试用例如下：
4.2.原则
由于根据程序的逻辑复杂程度以及程序设计上的差异性，某些代码想要完成特定的测试覆盖几乎是无法完成的，所以原则上不要求所有测试用例都能完成最高的代码覆盖度。
因此在条件允许的情况，尽量完成更高的测试覆盖度，最低要求是语句覆盖。
5.建议执行规范
考虑到规范的的复杂度与实施效果不成正比的关系，在单元测试方案的规范中只取最核心的几项进行规范化以便降低实施的难度的同时提高交付的系统的质量。
5.1.提交test测试包
Maven项目在main目录同级下默认了一个test包用于存放测试代码以及测试用配置文件，maven项目所编写的所有测试用代码和配置文件必须提交到SVN。
5.2.每个模块或类提交对应的测试类
每个模块或服务类有对应同名的测试类。
测试类中每个方法只进行一项最简单的单元测试，并且测试的方法必须有含义且与测试的逻辑相符合。
5.3.测试用例至少达到语句覆盖
编写测试代码的研发人员需要使用Cobertura或其他工具自检提交的单元测试代码，最低要求测试的覆盖率达到语句覆盖级别。
5.4.系统编译时需要执行所有测试类
编译机进行系统编译打包的时候需要执行test包底下的所有测试用例，必须所有测试用例都通过才允许打包部署。
6.实施
6.1.新项目
新项目采用maven构建，并且系统在生命周期内按照规范持续交付产出。
6.2.旧项目
6.2.1.Maven项目
逐步补充提交模块和服务类的单元测试用例，新增功能同时产出测试用例代码。
6.2.2.非maven项目
添加test测试包，逐步补充提交模块和服务类的单元测试用例，新增功能同时产出测试用例代码。
Ant编译打包时需要将test包下的所有单元测试执行一次，全部通过方可打包部署。