自动化单元测试并不是什么新鲜事物,它应该是团队持之以恒的事情,可能有很多团队知道如何去做,但是还做得不够好;还有不少团队不知道如何去做,甚至有一些旧系统还不敢去重构,还在坚持着Java中的main方法调用的方式来执行,在漫长等待构建结果。
本文主要讲基于Java项目如何做自动化单元测试的实践。
关于单元测试的意义,详细参考stackoverflow这篇文章:
http://stackoverflow.com/questions/67299/is-unit-testing-worth-the-effort,
Martin Fowler在博客中解释了TestPyramid,如下图所示:
TestPyramid
Unit是整个金字塔的基石(在建筑行业,基石是做建筑物基础的石头),如果基石不稳,Service和UI何谈有构建意义呢?只有基石稳如磐石,上层建筑才够坚固。
本来想拿瑞士做钟表的例子来说明下,但同事说的汽车例子更好。一辆汽车由许多配件组成,如果有以下两种选择,你会选择哪个呢?
答案不言而喻了。
实施单元测试,并不代表你的生产效率能提高迅猛,反而有时候阻碍了瞬间的生产效率(传统的开发一个功能,看似就算完成的动作,增加单元测试看起来无法是浪费时间),但是,它最直接的是提升产品质量,从而提升市场的形象,间接才会提升生产效率。
做产品,到底是要数量,还是质量呢?这个应该留给老板们去回答,看企业是否需要长远立足。
自动化单元测试有四个关键组成部分要做到统一,如图所示:
关键组成部分
版本控制系统(源代码控制管理系统)是保存文件多个版本的一种机制。一般来说,包括Subversion、Git在内的开源工具就可以满足绝大多数团队的需求。所有的版本控制系统都需要解决这样一个基础问题: 怎样让系统允许用户共享信息,而不会让他们因意外而互相干扰?
如果没有版本控制工具的协助,在开发中我们经常会遇到下面的一些问题:
-
代码管理混乱。
-
解决代码冲突困难。
-
在代码整合期间引入深层BUG。
-
无法对代码的拥有者进行权限控制。
-
项目不同版本发布困难。
版本控制不仅仅针对源代码,每个与所开发的软件相关的产物都应该被置于版本控制下,应当包括:源代码、测试代码、数据库脚本、构建和部署脚本、文档、web容器(tomcat的配置)所用的配置文件等。
频繁提交可靠、有质量保证的代码(编译通过是最基本要求),能够轻松回滚到最近可靠的版本,代码提交之后能够触发持续集成构建,及时得到反馈。
强制要求团队成员使用有意义注释,甚至可以关联相关开发任务的原因是:当构建失败后,你知道是谁破坏了构建,找到可能的原因及定位缺陷位置。这些附加信息,可以缩短我们修复缺陷的时间。
示例:团队使用了svn和redmine,注释是:refs #任务id 提交说明
每个任务下可以看到多次提交记录:
相关修订版本
-
所有的代码文件编码格式统一使用UTF-8
-
上班前更新代码,下班前提交代码
前一天,团队其他成员可能提交了许多代码到svn,开始新的一天工作是,务必更新到最新版本,及时发现问题(例如代码冲突)并解决;
当日事,当日毕,下班别把当天的编码成果仅保存在本地,应当提交到svn,次日团队更新就可以获取到最新版本,形成良性循环。
Maven是基于项目对象模型(POM),通过为Java项目的代码组织结构定义描述信息来管理项目的构建、报告和文档的软件项目管理工具。使用“惯例胜于配置”(convention over configuration)的原则,只要项目按照Maven制定的方式进行组织,它就几乎能用一条命令执行所有的构建、部署、测试等任务,却不用写很多行的XML(消除Ant文件中大量的样板文件)。
或许,使用Ant来构建的团队要问,为什么用Maven呢?简单来说有三点原因:
说实话,ant处理依赖包之间的冲突问题,还是得靠人工解决,这个对于研发来说是消耗时间的,倒不如把节省的时间投入到业务中去。另外再也不用每个项目繁琐复制spring.jar了,通过maven自动管理Java库和项目间的依赖,打包的时候会将所有jar复制到WEB- INF/lib/目录下。
官方的约定:
http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
保证所有项目的目录结构在任何服务器上都是一样的,每个目录起什么作用都很清楚明了。
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
Maven2把软件开发的过程划分成了几个经典阶段,比如你先要生成一些java代码,再把这些代码复制到特定位置,然后编译代码,复制需要放到classpath下的资源,再进行单元测试,单元测试都通过了才能进行打包、发布。
JUnit是一个Java语言的单元测试框架。
2013年见过一个旧项目,测试代码还是以main作为入口,为什么要使用JUnit?
JUnit 的优点是整个测试过程无人值守,开发无须在线参与和判断最终结果是否正确,可以很容易地一次性运行多个测试,使得开发更加关注测试逻辑的编写,而不是增加构建维护时间。
团队示例代码:
Mockito是一个针对Java的mocking框架。使用它可以写出干净漂亮的测试用例和简单的API。它与EasyMock和jMock很相似,通过在执行后校验什么已经被调用,消除了对期望行为(expectations)的需要,改变其他mocking库以“记录-回放”(这会导致代码丑陋)的测试流程,使得自身的语法更像自然语言。
Mockito示例:
EasyMock示例:
官方对比文章:
http://code.google.com/p/mockito/wiki/MockitoVSEasyMock
持续集成平台: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%,涉及两个或两个以上,甚至更多模块之间交互的集成测试;