作者｜李乐

编辑｜穆寰

自动化单元测试并不是什么新鲜事物，它应该是团队持之以恒的事情，可能有很多团队知道如何去做，但是还做得不够好；还有不少团队不知道如何去做，甚至有一些旧系统还不敢去重构，还在坚持着Java中的main方法调用的方式来执行，在漫长等待构建结果。

本文主要讲基于Java项目如何做自动化单元测试的实践。

是否值得

关于单元测试的意义，详细参考stackoverflow这篇文章：

Martin Fowler在博客中解释了TestPyramid，如下图所示：

TestPyramid

Unit是整个金字塔的基石（在建筑行业，基石是做建筑物基础的石头），如果基石不稳，Service和UI何谈有构建意义呢？只有基石稳如磐石，上层建筑才够坚固。

本来想拿瑞士做钟表的例子来说明下，但同事说的汽车例子更好。一辆汽车由许多配件组成，如果有以下两种选择，你会选择哪个呢？

• 所有单元配件没有测试过，在4S店，销售人员告诉你：刚组装好，已经开了一天，能跑起来，你可以试试；

• 所有单元配件在生产过程已经经过严格测试，在4S点，销售人员告诉你，已经通过国家认证，出厂合格，有质量保证，你可以试试；

答案不言而喻了。

实施单元测试，并不代表你的生产效率能提高迅猛，反而有时候阻碍了瞬间的生产效率（传统的开发一个功能，看似就算完成的动作，增加单元测试看起来无法是浪费时间），但是，它最直接的是提升产品质量，从而提升市场的形象，间接才会提升生产效率。

做产品，到底是要数量，还是质量呢？这个应该留给老板们去回答，看企业是否需要长远立足。

关键部分

自动化单元测试有四个关键组成部分要做到统一，如图所示：

关键组成部分

（一）配置管理：使用版本控制

版本控制系统（源代码控制管理系统）是保存文件多个版本的一种机制。一般来说，包括Subversion、Git在内的开源工具就可以满足绝大多数团队的需求。所有的版本控制系统都需要解决这样一个基础问题: 怎样让系统允许用户共享信息，而不会让他们因意外而互相干扰？

如果没有版本控制工具的协助，在开发中我们经常会遇到下面的一些问题：

• 代码管理混乱。

• 解决代码冲突困难。

• 在代码整合期间引入深层BUG。

• 无法对代码的拥有者进行权限控制。

• 项目不同版本发布困难。

对所有内容都进行版本控制

版本控制不仅仅针对源代码，每个与所开发的软件相关的产物都应该被置于版本控制下，应当包括：源代码、测试代码、数据库脚本、构建和部署脚本、文档、web容器（tomcat的配置）所用的配置文件等。

保证频繁提交可靠代码到主干

频繁提交可靠、有质量保证的代码（编译通过是最基本要求），能够轻松回滚到最近可靠的版本，代码提交之后能够触发持续集成构建，及时得到反馈。

提交有意义的注释

强制要求团队成员使用有意义注释，甚至可以关联相关开发任务的原因是：当构建失败后，你知道是谁破坏了构建，找到可能的原因及定位缺陷位置。这些附加信息，可以缩短我们修复缺陷的时间。

示例：团队使用了svn和redmine，注释是：refs #任务id 提交说明

每个任务下可以看到多次提交记录：

相关修订版本

• 所有的代码文件编码格式统一使用UTF-8

• 上班前更新代码，下班前提交代码

前一天，团队其他成员可能提交了许多代码到svn，开始新的一天工作是，务必更新到最新版本，及时发现问题（例如代码冲突）并解决；

当日事，当日毕，下班别把当天的编码成果仅保存在本地，应当提交到svn，次日团队更新就可以获取到最新版本，形成良性循环。

构建管理：使用Maven构建工具

Maven是基于项目对象模型(POM)，通过为Java项目的代码组织结构定义描述信息来管理项目的构建、报告和文档的软件项目管理工具。使用“惯例胜于配置”（convention over configuration）的原则，只要项目按照Maven制定的方式进行组织，它就几乎能用一条命令执行所有的构建、部署、测试等任务，却不用写很多行的XML（消除Ant文件中大量的样板文件）。

或许，使用Ant来构建的团队要问，为什么用Maven呢？简单来说有三点原因：

1、对第三方依赖库进行统一的版本管理

说实话，ant处理依赖包之间的冲突问题，还是得靠人工解决，这个对于研发来说是消耗时间的，倒不如把节省的时间投入到业务中去。另外再也不用每个项目繁琐复制spring.jar了，通过maven自动管理Java库和项目间的依赖，打包的时候会将所有jar复制到WEB- INF/lib/目录下。

2、统一项目的目录结构。

保证所有项目的目录结构在任何服务器上都是一样的，每个目录起什么作用都很清楚明了。

3、统一软件构建阶段

Maven2把软件开发的过程划分成了几个经典阶段，比如你先要生成一些java代码，再把这些代码复制到特定位置，然后编译代码，复制需要放到classpath下的资源，再进行单元测试，单元测试都通过了才能进行打包、发布。

（三）测试框架：JUnit&Mockito

JUnit

JUnit是一个Java语言的单元测试框架。

2013年见过一个旧项目，测试代码还是以main作为入口，为什么要使用JUnit？

JUnit 的优点是整个测试过程无人值守，开发无须在线参与和判断最终结果是否正确，可以很容易地一次性运行多个测试，使得开发更加关注测试逻辑的编写，而不是增加构建维护时间。

团队示例代码：

Mockito

Mockito是一个针对Java的mocking框架。使用它可以写出干净漂亮的测试用例和简单的API。它与EasyMock和jMock很相似，通过在执行后校验什么已经被调用，消除了对期望行为（expectations）的需要，改变其他mocking库以“记录-回放”（这会导致代码丑陋）的测试流程，使得自身的语法更像自然语言。

Mockito示例：

EasyMock示例：

（四）反馈平台：Jenkins&Sonar

持续集成平台：Jenkins

Jenkins 的前身是 Hudson 是一个可扩展的持续集成引擎，主要用于：

• 持续、自动地构建测试软件项目

• 监控一些定时执行的任务

Jenkins将作为自动化单元测试持续集成的平台,实现自动化构建。

Jenkins平台

代码质量管理平台：Sonar

Sonar (SonarQube)是一个开源平台，用于管理源代码的质量。Sonar 不只是一个质量数据报告工具，更是代码质量管理平台。支持的语言包括：Java、PHP、C#、C、Cobol、PL/SQL、Flex 等。

主要特点：

• 代码覆盖：通过单元测试，将会显示哪行代码被选中

• 改善编码规则

• 搜寻编码规则：按照名字，插件，激活级别和类别进行查询

• 项目搜寻：按照项目的名字进行查询

• 对比数据：比较同一张表中的任何测量的趋势

Sonar将作为自动化单元测试反馈报告统一展现平台，包括：

Sonar将作为自动化单元测试反馈报告统一展现平台，包括：

单元测试覆盖率、成功率、代码注释、代码复杂度等度量数据的展现。

Sonar平台

遵循原则

自动化测试金字塔，也称为自动化分层测试，Unit是整个金字塔的基石，最重要特点是运行速度非常快；第二个重要特点是UT应覆盖代码库的大部分，能够确定一旦UT通过后，应用程序就能正常工作。

Unit：70%，大部分自动化实现，用于验证一个单独函数或独立功能模块的代码；

Service：20%，涉及两个或两个以上，甚至更多模块之间交互的集成测试；

UI：10%，覆盖三个或以上的功能模块，真实用户场景和数据的验收测试；

这里仅仅列举了每个层次的百分比，实际要根据团队的方向来做调整。

自动化单元测试原则

提交代码、运行测试的重点是什么？快速捕获那些因修改向系统中引入的最常见错误，并通知开发人员，以便他们能快速修复他们。提交阶段提供反馈的价值在于，对它的投入可以让系统高效且更快地工作。

隔离UI操作

UI应当作为更高层次的测试Level，需要花费大量时间准备数据，业务逻辑复杂，过早进入UI阶段，容易分散开发的单元测试精力。

隔离数据库以及文件读写网络开销等操作

自动化测试中如果需要将结果写入数据库，然后再验证改结果是否被正确写入，这种验证方法简单、容易理解，但是它不是一个高效的方法。这个应当从集成测试的Level去解决。

首先：与数据库的交互，是漫长的，甚至有可能要投入维护数据库的时间，那将成为快速测试的一个障碍，开发人员不能得到及时有效的反馈。假设，我需要花费一个小时，才能验证完毕与数据库交互的结果，这种等待是多么漫长呀。

其次，数据管理需要成本，从数据的筛选（线上数据可能是T级）到测试环境的M级别，如何把筛选合适的大小，这都使得管理成本增加（当然在集成测试中可以使用DBUnit来解决部分问题）。

最后，如果一定要有读写操作才能完成的测试，也要反思代码的可测试性做的如何？是否需要重构。

单元测试决不要依赖于数据库以及文件系统、网络开销等一切外部依赖。

使用Mock替身与Spring容器隔离

如果在单元测试中，还需要启动Spring容器进行依赖注入、加载依赖的WebService等，这个过程是相当消耗时间的。

可以使用模拟工具集：Mockito、EasyMock、JMock等来解决，研发团队主要是基于Mockito的实践。与需要组装所有的依赖和状态相比，使用模拟技术的测试运行起来通常是非常快，这样子开发人员在提交代码之后，可以在持续集成平台快速得到反馈。

设计简单的测试

明确定义方法：

成功：public void testSendReportLongDateSuccess

失败：public void testSendReportLongDateFail，可以包括异常

和单一的断言，避免在一个方法内使用多个复杂断言，这会造成代码结构的复杂，使得测试的复杂性提高。

定义测试套件的运行时间

使用Mock构建的单元测试，每个方法的构建时间应该是毫秒级别，整个类是秒级别，理想的是整体构建时间控制在5分钟以内，如果超过怎么办呢？

首先，拆分成多个套件，在多台机器上并行执行这些套件；

其次，重构那些运行时间比较长且不经常失败的测试类；