自动化单元测试实践之路(3)

　　2.监控一些定时执行的任务

　　Jenkins将作为自动化单元测试持续集成的平台,实现自动化构建。

　　图-2-3-Jenkins平台

　　代码质量管理平台：Sonar

　　Sonar (SonarQube)是一个开源平台，用于管理源代码的质量。Sonar 不只是一个质量数据报告工具，更是代码质量管理平台。支持的语言包括：Java、PHP、C#、C、Cobol、PL/SQL、Flex 等。

　　主要特点：

　　1.代码覆盖：通过单元测试，将会显示哪行代码被选中

　　2.改善编码规则

　　3.搜寻编码规则：按照名字，插件，激活级别和类别进行查询

　　4.项目搜寻：按照项目的名字进行查询

　　5.对比数据：比较同一张表中的任何测量的趋势

　　Sonar将作为自动化单元测试反馈报告统一展现平台，包括：

　　单元测试覆盖率、成功率、代码注释、代码复杂度等度量数据的展现。

　　图-2-4 Sonar平台

　　3 原则

　　自动化测试金字塔，也称为自动化分层测试，Unit是整个金字塔的基石，最重要特点是运行速度非常快;第二个重要特点是UT应覆盖代码库的大部分，能够确定一旦UT通过后，应用程序就能正常工作。

　　Unit：70%，大部分自动化实现，用于验证一个单独函数或独立功能模块的代码;

　　Service：20%，涉及两个或两个以上，甚至更多模块之间交互的集成测试;

　　UI：10%，覆盖三个或以上的功能模块，真实用户场景和数据的验收测试;

　　这里仅仅列举了每个层次的百分比，实际要根据团队的方向来做调整。

　　自动化单元测试原则

　　提交代码、运行测试的重点是什么?快速捕获那些因修改向系统中引入的最常见错误，并通知开发人员，以便他们能快速修复他们。提交阶段提供反馈的价值在于，对它的投入可以让系统高效且更快地工作。

　　1、隔离UI操作

　　UI应当作为更高层次的测试Level，需要花费大量时间准备数据，业务逻辑复杂，过早进入UI阶段，容易分散开发的单元测试精力。

　　2、隔离数据库以及文件读写网络开销等操作

　　自动化测试中如果需要将结果写入数据库，然后再验证改结果是否被正确写入，这种验证方法简单、容易理解，但是它不是一个高效的方法。这个应当从集成测试的Level去解决。

　　首先：与数据库的交互，是漫长的，甚至有可能要投入维护数据库的时间，那将成为快速测试的一个障碍，开发人员不能得到及时有效的反馈。假设，我需要花费一个小时，才能验证完毕与数据库交互的结果，这种等待是多么漫长呀。

　　其次，数据管理需要成本，从数据的筛选(线上数据可能是T级)到测试环境的M级别，如何把筛选合适的大小，这都使得管理成本增加(当然在集成测试中可以使用DBUnit来解决部分问题)。

　　最后，如果一定要有读写操作才能完成的测试，也要反思代码的可测试性做的如何?是否需要重构。

　　单元测试决不要依赖于数据库以及文件系统、网络开销等一切外部依赖。

　　3、使用Mock替身与Spring容器隔离

　　如果在单元测试中，还需要启动Spring容器进行依赖注入、加载依赖的WebService等，这个过程是相当消耗时间的。

　　可以使用模拟工具集：Mockito、EasyMock、JMock等来解决，研发团队主要是基于Mockito的实践。与需要组装所有的依赖和状态相比，使用模拟技术的测试运行起来通常是非常快，这样子开发人员在提交代码之后，可以在持续集成平台快速得到反馈。

　　4、设计简单的测试

　　明确定义方法：

　　成功：public void testSendReportLongDateSuccess()

　　失败：public void testSendReportLongDateFail()，可以包括异常

　　和单一的断言，避免在一个方法内使用多个复杂断言，这会造成代码结构的复杂，使得测试的复杂性提高。

　　5、定义测试套件的运行时间

　　使用Mock构建的单元测试，每个方法的构建时间应该是毫秒级别，整个类是秒级别，理想的是整体构建时间控制在5分钟以内，如果超过怎么办呢?

　　首先，拆分成多个套件，在多台机器上并行执行这些套件;

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