官方对比文章：http://code.google.com/p/mockito/wiki/MockitoVSEasyMock
　　反馈平台：Jenkins&Sonar
　　持续集成平台：Jenkins
　　Jenkins 的前身是 Hudson 是一个可扩展的持续集成引擎，主要用于：
　　持续、自动地构建测试软件项目
　　监控一些定时执行的任务
　　Jenkins将作为自动化单元测试持续集成的平台，实现自动化构建。

 

图-2-3-Jenkins平台


　　代码质量管理平台：Sonar
　　Sonar (SonarQube)是一个开源平台，用于管理源代码的质量。Sonar 不只是一个质量数据报告工具，更是代码质量管理平台。支持的语言包括：Java、PHP、C#、C、Cobol、PL/SQL、Flex 等。
　　主要特点：
　　代码覆盖：通过单元测试，将会显示哪行代码被选中
　　改善编码规则
　　搜寻编码规则：按照名字，插件，激活级别和类别进行查询
　　项目搜寻：按照项目的名字进行查询
　　对比数据：比较同一张表中的任何测量的趋势
　　Sonar将作为自动化单元测试反馈报告统一展现平台，包括：
　　单元测试覆盖率、成功率、代码注释、代码复杂度等度量数据的展现。

图-2-4 Sonar平台


　　3 原则
　　自动化测试金字塔，也称为自动化分层测试，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分钟以内，如果超过怎么办呢？
　　首先，拆分成多个套件，在多台机器上并行执行这些套件；
　　其次，重构那些运行时间比较长且不经常失败的测试类；
　　更多参考推荐阅读：《Unit Testing Guidelines》
　　http://geosoft.no/development/unittesting.html