自动化单元测试实践之路

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

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

　　1 是否值得

　　TestPyramid，如下图所示：

　　图-1-1-TestPyramid

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

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

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

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

　　答案不言而喻了。

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

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

　　2 关键部分

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

　　图-2-1-关键组成部分

　　配置管理：使用版本控制

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

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

　　一、 代码管理混乱。

　　二、 解决代码冲突困难。

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

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

　　五、 项目不同版本发布困难。

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

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

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

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

　　提交有意义的注释

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

　　refs #任务id 提交说明

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

　　图-2-2-相关修订版本

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

　　2.上班前更新代码，下班前提交代码

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

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

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

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

原文转自：http://www.uml.org.cn/Test/201407281.asp