基于mockito做有效的单元测试

发表于:2019-9-02 10:38

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:地藏Kelvin    来源:掘金

  本文讲解的主要是有效和单元的思想,并不是说如何编写单元测试,用于改善和提高开发效率、编码风格、编码可读性和单测效率,不盲目追求覆盖率。
  背景
  现在很多单元测试只是利用@Test注解把代码或者整个请求接口内的business做测试
  单测的过程就很多查数据库的方法,但是没必要每次都测sql,因为sql测一遍都应该是正确的。
  未明确单元测试由开发负责。单元测试是用于维护代码逻辑不被修改或者,修改了也不出错,不是测试的事情。
  单测代码启动速度、效率太低
  没有在各个环境整个工程单元测试通过
  方法写的很大,行数很多,边update边做逻辑
  很多公司盲目追求覆盖率
  目的
  单元测试启动效率提升
  脱离环境,在每个环境都放心执行,不要考虑测试环境、生产环境有没有这条数据
  维护方法核心逻辑在后续的迭代中不被错误地修改
  用于改善和提高开发效率、编码质量、编码可读性、减少冗长的代码行
  什么是有效的单元测试
  主要关键字: 有效、单元
  有效
  单元
  覆盖场景
  可重复执行
  断言
  不追求覆盖率
  1.有效的定义
  只测试核心的业务逻辑,如计算逻辑类(指标计算)、用户支付下单组装数据库对象和子表(检验金额)、创建采买计划表和detail表的对象(校验指标个数、金额)
  不测用户交互的,如导出数据excel的底色、查询数据库记录
  不测逻辑的前置校验
  不要测试明显有用的东西。避免测试来自第三方供应商的类,特别是提供编写代码的框架的核心API的类。例如,不要测试向供应商的Hashtable类添加项、redis锁等第三方库
  不测环境相关的,尽量脱离环境,能让单测代码在每个环境都能正确执行。
  2.单元的定义
  “单元测试”中的“单元”的意思是,将每个单元设为原子和尽可能独立。
  目的:方法小,则可能组件化地再次利用,维护逻辑在以后的迭代中不被错误的修改。若被错误修改,只要每次迭代都走全工程的单测时将会报错而被发现。
  使得编写代码时方法职责单一,方法功能要小,方法逻辑小。也不要写多行数方法,以多个小方法组成一个长逻辑。
  单测时不要写大测试
  逻辑代码方法尽量不互相依赖。没有关于测试执行顺序的假设。
  逻辑代码方法适当的小,则能容易安装/拆卸。
  单测时没必要把全流程都测一遍,也就是不必从controller遇到的第一个business入口测。只测核心逻辑,也就是核心的每个小方法的测试。
  样例:
   public void updateUser(String userName,Integer age) {
  // 校验
  if (StringUtils.isEmpty(userName)) {
  throw new RuntimeException();
  }
  // redis分布式锁
  getRedis();
  // 查询主表
  selectUser();
  // 查询出采买计划Detail
  selectUserDetail();
  // 对数据进行处理
  calculateUserDetailInfo();
  //  更新主表
  updatePuchasePlanDb();
  //  更新detail表
  updatePuchasePlanDbDetail();
  }
   假设上述updateUser是一个Controller下的第一个business逻辑入口,用于更新用户信息,很多人的单元测试就会从updateUser这个方法开始做单元测试。但是这样就不符合有效、单元的理念。
  无意义测试
  因为如redis这些第三方库,我们是相信他是正确的,而且走redis是需要连接真实网络,所以就会依赖环境,万一网络不通,单元测试这段代码就无法通过。
  前置校验也不用测,因为错误率和以后改动的机会比较少
  查询数据库主表、detail表、更新也不用测试,因为都是SQL,单元测试是为了维护逻辑不变,这些sql写好一遍能正确,以后的迭代中都是正确的。
  有意义测试
  所以我们单测的时候只测数据处理的逻辑,假设数据处理逻辑如下,则对下面的3个方法每个做一个单元测试。
  我们会认为组件式的方法能正确,组合起来就大概率正确。因为方法足够的单元,则逻辑可插拔。
  若从头测到尾,以后迭代中逻辑改动的概率很大,断言错误概率大,这样单元测试维护的意义就很小。
   private void calculateUserDetailInfo() {
  // 更改公司与关联上下级关系
  changeCompany();
  // 更改组与关联上下级关系
  changeGroup();
  // 更改部门与关联上下级关系
  changeDeptment();
  }
  错误编码案例:
   private void calculateBrand() {
  for (int i = 0; i < new ArrayList<>().size(); i++) {
  for (int i1 = 0; i1 < new ArrayList<>().size(); i1++) {
  if (new Integer(1)==1) {
  }  else {
  }
  }
  }
  }
   这样的代码就不符合单元的概念,至少把第二个for循环写在另外一个方法里,因为单元测试中,认为测试循环中一次是正确的,就断言循环中每次都大概率正确。
  3.覆盖场景
  除了测试正常流程,还要测异常流程
  覆盖方法正常运行,为其创建一个单测
  覆盖if else,为同一个方法创建第二个单测
  案例一 异常流程
   public Integer logic2(Integer num) throws Exception {
  try {
  num = this.purchasePlanDetailBusinessImpl.method(num);
  } catch (RuntimeException e) {
  throw new Exception();
  }
  return ++num;
  }
  则对应编写:
   /**
  * 测试异常场景
  */
  @Test(expected = Exception.class)
  public void testMethodOnException() {
  Integer method = this.purchasePlanBusinessImpl.logic(null);
  }
 4.断言
  很多人的单元测试都是最后print一下,在console里面看日志或者debug看看是否正确,但是这样不足够。
  应有对方法返回值、对象里面的成员属性做判断
  判断是否为空或者判断金额数值或者判断异常是否符合预期
  只测试一件事一次。只要1个断言测试一或者多个特性/行为
  如下,而不是直接判断是否为空或输出到终端
  @Test
  public void testMethodOnNormal() {
  Integer method = this.purchasePlanBusinessImpl.method(1);
  Assert.assertTrue(method == 2);
  }
  5.可重复执行
  目前很多操作数据库,或者内存数据库
  操作真实数据库,有可能下次就不能被断言成功了,因为数据有可能被update
  内存数据库虽然可以下次启动依然恢复默认的数据,但是有可能被其他人的单测操作过,导致自己的数据被错误修改
  6.不盲目追求覆盖率
  很多公司盲目追求覆盖率,说美国google覆盖多高,但是别人工资高,6点准时下班,有足够时间开发,开发前uml设计好每个方法的入参出参,在中国是没有这么多时间,都是追求快速
  在中国大厂中,虽然有覆盖率要求,但是覆盖率只能证明你有没有写单元测试,但是单元测试写的好不好,就是另外一回事。因为有些人为了提高覆盖率,把一些无关的代码也去单元测试,如测试controller层、测试entity构造函数、utils工具类等。
  蚂蚁金服作为样例,蚂蚁是根据项目分覆盖级别,也不是所有的项目都要覆盖率多高,一般50%就很高了,不必都过50%,本文主要推崇的是有效、单元。
  按照本文的有效、单元的做法,是会牺牲覆盖率的,因为我们只测核心逻辑
  不浪费时间,因为中国互联网的迭代时间非常短,所以不必盲目为覆盖率而写单元测试,单元测试的目的是提供代码质量
  操作工具
  mockito:一般都能适用
  powermock:在mockito的基础上,能测试private方法,还能mock static静态方法
  @InjectMocks 用于框架new出对象,不用手动new 主要测试类
  @Mock:被设置假对象返回的调用类
  Assert.assertTrue等断言
  JSONObejct、JSONString:有时自己mock对象需要自己new ,但是这个时候我们可以写好json体转换成bean会比较方便。
   <dependencies>
  <dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-test</artifactId>
  <version>4.3.7.RELEASE</version><!--$NO-MVN-MAN-VER$ -->
  <scope>test</scope>
  </dependency>
  <!-- https://mvnrepository.com/artifact/org.mockito/mockito-all -->
  <dependency>
  <groupId>org.mockito</groupId>
  <artifactId>mockito-all</artifactId>
  <version>1.10.19</version>
  <scope>test</scope>
  </dependency>
  <dependency>
  <groupId>org.mockito</groupId>
  <artifactId>mockito-core</artifactId>
  <version>2.7.12</version>
  <scope>test</scope>
  </dependency>
  <!-- https://mvnrepository.com/artifact/junit/junit -->
  <dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>4.12</version>
  <scope>test</scope>
  </dependency>
  <dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-context</artifactId>
  <version>4.3.7.RELEASE</version><!--$NO-MVN-MAN-VER$ -->
  </dependency>
  <dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-core</artifactId>
  <version>4.3.7.RELEASE</version><!--$NO-MVN-MAN-VER$ -->
  </dependency>
  <dependency>
  <groupId>org.projectlombok</groupId>
  <artifactId>lombok</artifactId>
  <version>1.18.8</version>
  <scope>provided</scope>
  </dependency>
  </dependencies>
  
   @RunWith(MockitoJUnitRunner.class)
  public class PurchasePlanBusinessImplTest {
  @InjectMocks
  private DoSomeBusinessImpl purchasePlanBusinessImpl;
  @Mock
  private DoSomeDetailBusinessImpl purchasePlanDetailBusinessImpl;
  /**
  * 正常流程
  */
  @Test
  public void testMethodOnNormal() {
  Integer method = this.purchasePlanBusinessImpl.method(1);
  Assert.assertTrue(method == 2);
  }
  /**
  * 在某些场景
  */
  @Test
  public void testMethodOnXX() {
  when(this.purchasePlanDetailBusinessImpl.method(anyInt())).thenReturn(1);
  Integer method = this.purchasePlanBusinessImpl.logic(1);
  Assert.assertTrue(method == 3);
  }
   影响力
  效率提升
  目前测试要么启动服务、要么单测启动spring,其实都需要时间,无论是10几秒还是几分钟都是比较久的
  如果用mock方法,都是不需要基于sring容器,不需要自动注入就不需要解析bean关系,也不需要连接zk等环境问题。启动时间只需要1秒
  不需要在真实数据库造数据、不需要在内存数据库写sql
  如果测试整个工程的所有单测时,每一个类单元测试都会加载一次spring、内存数据库,导致跑整个工程都很久(实际上测试环境、回归环境都需要跑单测)
  脱离环境
  其实每个环境,无论开发联调、测试、回顾、甚至生产环境都在构建时执行单元测试
  但是因为使用spring容器启动的方式,每个类的单测都需要启动spring,导致执行时间过长
  也或者因为环境出现造数据问题,导致执行不成功
  mock出来的数据都是在代码实现,运行于内存中,所以不依赖中间件
  方法小、行数少、职责小
  职责小:因单元测试的规则,让写每个方法时,都有意识地写的少依赖,这样的方法就提示被其他逻辑复用的概览,而不是大方法,导致要用差不多的逻辑时,其他同事就会去复制一份代码。(例如不会在一个方法又做查询数据库、校验、计算)
  提高方法被其他逻辑利用的概率,因为大方法很难重复利用
  规范
  单元测试类以被测类的实现类为基础加Test,如xxxBusinessImpTest
  单元测试类需要放在test目录下,并且包名与被测类的路径一致,防止idea、sonar跑覆盖率校验时,没覆盖到对应的方法。
  方法命名:test开头,加真正的方法名,加场景,如testMethodOnNormal、testMethodOnException、testMethodOnLackOfMoney
  方法一般情况下都带返回值,即使没有返回值也写boolean。
  若是流程性方法等,可以为void,如责任链设计模式时
  必须断言,而不是print。断言值、正确与否、预期异常
  尽可能把查数据的逻辑写在被测方法之前,被测方法只做业务逻辑处理,不做查数据,这样单测时需要mock的方法会比较少。
  公司技术体系不一定会预留单元测试时间,很少公司愿意花时间在质量和维护上。都是赶着完成任务。
  例如3天开发,1天单元测试,1天sonar+review,1天联调,不一定有时间做得完善。

      上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号