优秀单元测试实战（二）

前言

上篇详细讲解了优秀单元测试的定义和价值，本篇将详解如何编写规范的单元测试，以及相关实战范例的内容。

3

编写规范的单元测试

1、测试类名、方法名命名规范

单元测试类名应为被测试类名后加Test，单个测试方法名格式为test+首字母大写的被测方法名。若该方法需要覆盖测试多种场景，可在其后加测试描述，如testConfirmForQuickpay。

2、编写可读的单元测试代码

优秀的单元测试是一种无价的文档，所以应该编写结构清晰、相当注释量的单元测试代码。另单元测试代码中，不应包含包含switch、if/else、for/while等控制流语句，复杂度高且可读性差。

3、单个测试方法应构建具有确定性结果

每个单元测试方法都应具有确定性的结果，并做相应的断言验证。若测试结果验证不够详细，无法确保功能的正确性。若测试无参返回的方法，应对方法执行后预期的结果进行验证。

4、测试类仅测试一个类，测试方法仅测试一个方法

一个测试方法只能用来测试一种行为，不应对多个方法进行测试及结果验证。

5、应使用断言而不是Print语句

禁止使用print的方式输出后人工判断，人工判断无法实现单元测试的自动化，应正确使用断言，验证测试结果的正确性。另不应使用已废弃的junit.framework.Assert，应使用org.junit.Assert。

6、测试方法中不应使用try catch捕获异常

对于异常的测试方法，应使用期望异常。注意期望异常(@Rule ExpectedException)需要使用public，且不应放在测试基类中，因为每个测试方法都会执行该规则，请谨慎使用。对于未知异常，也不应使用try catch，junit本身会捕获异常，若非期望异常会不通过。

7、拒绝过度保护

过分保护的测试代码，基本上是不能提供附加价值的断言和测试语句，应删除冗余的断言。

8、拒绝过度断言

当遇到过度断言，很难理解其测试意图，可能会导致程序变化会造成输出与期望不同。

9、拒绝重复的测试代码

重复就是导致代码失去整洁的罪魁祸首之一，使得散落在各处的概念和逻辑很难理解。应适时抽取相同的代码逻辑，进行封装设计，抽取测试基类进行公共数据、配置集中管理，保证测试代码的整洁。

10、应保持单个测试方法的独立性

单个测试方法应具有独立性，不应依赖先前测试方法的结果，防止数据依赖导致所有测试用例失败。如果需要初始化数据，可使用Mock。

11、不应使用@Ignore

忽略方法没有意义，SonarLint也会告警。

12、防止引入测试脏数据

若使用了数据库的，可使用spring-test的事务回滚机制，防止进行单元测试时，产生无用的垃圾数据。在高版本的Spring框架中（Spring4.2以后），@TransactionConfiguration已经标注为过时的注解，可使用@Rollback进行数据回滚。

结语

本篇主要讲解了如何编写规范的单元测试，规范的单元测试对我们意义重大，为后期维护源代码提供了一份可编译、可运行的API文档。下篇将详解如何编写可靠的单元测试，敬请关注。另关于单元测试的编写规范，可参见：

http://confluence.midea.com/pages/viewpage.action?pageId=15863857

—END—