自动化单元测试并不是什么新鲜事物，它应该是团队持之以恒的事情，可能有很多团队知道如何去做，但是还做得不够好；还有不少团队不知道如何去做，甚至有一些旧系统还不敢去重构，还在坚持着Java中的main方法调用的方式来执行，在漫长等待构建结果。
本文主要讲基于Java项目如何做自动化单元测试的实践。
1 是否值得
关于单元测试的意义，详细参考stackoverflow这篇文章：
http://stackoverflow.com/questions/67299/is-unit-testing-worth-the-effort，
Martin Fowler在博客（http://martinfowler.com/bliki/TestPyramid.html）中解释了
TestPyramid，如下图所示：
Unit是整个金字塔的基石（在建筑行业，基石是做建筑物基础的石头），如果基石不稳，Service和UI何谈有构建意义呢？只有基石稳如磐石，上层建筑才够坚固。
本来想拿瑞士做钟表的例子来说明下，但同事说的汽车例子更好。一辆汽车由许多配件组成，如果有以下两种选择，你会选择哪个呢？
所有单元配件没有测试过，在4S店，销售人员告诉你：刚组装好，已经开了一天，能跑起来，你可以试试；
所有单元配件在生产过程已经经过严格测试，在4S点，销售人员告诉你，已经通过国家认证，出厂合格，有质量保证，你可以试试；
答案不言而喻了。
实施单元测试，并不代表你的生产效率能提高迅猛，反而有时候阻碍了瞬间的生产效率（传统的开发一个功能，看似就算完成的动作，增加单元测试看起来无法是浪费时间），但是，它最直接的是提升产品质量，从而提升市场的形象，间接才会提升生产效率。
做产品，到底是要数量，还是质量呢？这个应该留给老板们去回答，看企业是否需要长远立足。
2 关键部分
自动化单元测试有四个关键组成部分要做到统一，如图所示：
图-2-1-关键组成部分
配置管理：使用版本控制
版本控制系统（源代码控制管理系统）是保存文件多个版本的一种机制。一般来说，包括Subversion、Git在内的开源工具就可以满足绝大多数团队的需求。所有的版本控制系统都需要解决这样一个基础问题: 怎样让系统允许用户共享信息，而不会让他们因意外而互相干扰？
如果没有版本控制工具的协助，在开发中我们经常会遇到下面的一些问题：
一、 代码管理混乱。
二、 解决代码冲突困难。
三、 在代码整合期间引入深层BUG。
四、 无法对代码的拥有者进行权限控制。
五、 项目不同版本发布困难。
对所有内容都进行版本控制
