优秀单元测试实战(二)

前言

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

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—

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180821G1813M00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券