自动化单元测试并不是什么新鲜事物，它应该是团队持之以恒的事情，可能有很多团队知道如何去做，但是还做得不够好；还有不少团队不知道如何去做，甚至有一些旧系统还不敢去重构，还在坚持着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-关键组成部分