JUnit5学习之二:Assumptions类

简介: 学习Assumptions类的用法

欢迎访问我的GitHub

这里分类和汇总了欣宸的全部原创(含配套源码):https://github.com/zq2599/blog_demos

关于《JUnit5学习》系列

《JUnit5学习》系列旨在通过实战提升SpringBoot环境下的单元测试技能,一共八篇文章,链接如下:

名称 链接 备注
项目主页 https://github.com/zq2599/blog_demos 该项目在GitHub上的主页
git仓库地址(https) https://github.com/zq2599/blog_demos.git 该项目源码的仓库地址,https协议
git仓库地址(ssh) git@github.com:zq2599/blog_demos.git 该项目源码的仓库地址,ssh协议
  • 这个git项目中有多个文件夹,本章的应用在junitpractice文件夹下,如下图红框所示:
    在这里插入图片描述

  • junitpractice是父子结构的工程,本篇的代码在assertassume子工程中,如下图:
    在这里插入图片描述

    Assertions和Assumptions简介

    Assumptions和Assertions容易混淆,因此这里通过对比它们来学习:

  • Assertions即断言类,里面提供了很多静态方法,例如assertTrue,如果assertTrue的入参为false,就会抛出AssertionFailedError异常,Junit对抛出此异常的方法判定为失败;
  • Assumptions即假设类,里面提供了很多静态方法,例如assumeTrue,如果assumeTrue的入参为false,就会抛出TestAbortedException异常,Junit对抛出此异常的方法判定为跳过;
  • 简单的说,Assertions的方法抛出异常意味着测试不通过,Assumptions的方法抛出异常意味着测试被跳过(为什么称为"跳过"?因为mvn test的执行结果被标记为Skipped);

    写一段代码对比效果

  • 用代码来验证的效果最好,如下所示,一共四个方法,assertSuccess不抛出AssertionFailedError异常,assertFail抛出AssertionFailedError异常,assumpSuccess不抛出TestAbortedException异常,assumpFail抛出TestAbortedException异常
package com.bolingcavalry.assertassume.service.impl;

import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.boot.test.context.SpringBootTest;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assumptions.assumeTrue;

@SpringBootTest
@Slf4j
public class AssertAssumpTest {
   
   

    /**
     * 最简单的成功用例
     */
    @Test
    void assertSuccess() {
   
   
        assertEquals(2, Math.addExact(1,1));
    }

    /**
     * 最简单的失败用例
     */
    @Test
    void assertFail() {
   
   
        assertEquals(3, Math.addExact(1,1));
    }

    /**
     * assumeTrue不抛出异常的用例
     */
    @Test
    void assumpSuccess() {
   
   
        // assumeTrue方法的入参如果为true,就不会抛出异常,后面的代码才会继续执行
        assumeTrue(true);
        // 如果打印出此日志,证明assumeTrue方法没有抛出异常
        log.info("assumpSuccess的assumeTrue执行完成");
        // 接下来是常规的单元测试逻辑
        assertEquals(2, Math.addExact(1,1));
    }

    /**
     * assumeTrue抛出异常的用例
     */
    @Test
    void assumpFail() {
   
   
        // assumeTrue方法的入参如果为false,就会抛出TestAbortedException异常,后面就不会执行了
        assumeTrue(false, "未通过assumeTrue");
        // 如果打印出此日志,证明assumpFail方法没有抛出异常
        log.info("assumpFail的assumeTrue执行完成");
        // 接下来是常规的单元测试逻辑,但因为前面抛出了异常,就不再执行了
        assertEquals(2, Math.addExact(1,1));
    }
}
  • 点击下图红框位置执行单元测试:
    在这里插入图片描述
  • 执行结果如下:
    在这里插入图片描述
  • 另外,在target目录,可以看到surefire插件生成的单元测试报告TEST-com.bolingcavalry.assertassume.service.impl.AssertAssumpTest.xml,如下图所示,testcase节点中出现了skipped节点:
    在这里插入图片描述

  • 上述对比验证再次说明Assertions和Assumptions的区别:都用来对比预期值和实际值,当预期值和实际值不一致时,Assertions的测试结果是执行失败,Assumptions的测试结果是跳过(或者忽略);

    Assumptions实战

    弄清楚的Assertions和Assumptions的区别,接下来趁热打铁,学习Assumptions类中几个重要的静态方法:assumeTrue、assumingThat

  • 最简单的用法如下,可见只有assumeTrue不抛出异常,后面的log.info才会执行:
    @Test
    @DisplayName("最普通的assume用法")
    void tryAssumeTrue() {
   
   
        assumeTrue("CI".equals(envType));

        log.info("CI环境才会打印的assumeTrue");
    }
  • assumeTrue可以接受Supplier类型作为第二个入参,如果assumeTrue失败就会将第二个参数的内容作为失败提示:
@Test
    @DisplayName("assume失败时带自定义错误信息")
    void tryAssumeTrueWithMessage() {
   
   
        // 第二个入参是Supplier实现,返回的内容用作跳过用例时的提示信息
        assumeTrue("CI".equals(envType),
                () -> "环境不匹配而跳过,当前环境:" + envType);

        log.info("CI环境才会打印的tryAssumeTrueWithMessage");
    }

效果如下图:
在这里插入图片描述

  • 还有个assumingThat方法,可以接受Executable类型作为第二个入参,如果第一个入参为true就会执行Executable的execute方法,注意assumingThat方法的特点:不抛出异常,因此其所在的方法不会被跳过,这是和assumeTrue相比最大的区别(assumeTrue一旦入参为false就会抛出异常,其所在方法就被标记为跳过):

      @Test
      @DisplayName("assume成功时执行指定逻辑")
      void tryAssumingThat() {
          // 第二个入参是Executable实现,
          // 当第一个参数为true时,执行第二个参数的execute方法
          assumingThat("CI".equals(envType),
                  () -> {
                      log.info("这一行内容只有在CI环境才会打印");
                  });
    
          log.info("无论什么环境都会打印的tryAssumingThat");
      }
    
  • 接下来咱们执行上述代码,看看效果;

    执行Assumptions代码

  • 先做准备工作,本次实战的springboot工程名为assertassume,咱们在工程的resources目录下添加两个配置文件:application.properties和application-test.properties,位置如下图:
    在这里插入图片描述
  • application-test.properties内容如下:
    envType:CI
    
  • application.properties内容如下:
    envType:PRODUCTION
    
  • 完整的单元测试类如下,通过注解ActiveProfiles,指定了使用application-test.properties的配置,因此envType的值为CI
package com.bolingcavalry.assertassume.service.impl;

import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.ActiveProfiles;
import static org.junit.jupiter.api.Assumptions.assumeTrue;
import static org.junit.jupiter.api.Assumptions.assumingThat;

@SpringBootTest
@Slf4j
@ActiveProfiles("test")
public class AssumptionsTest {
   
   

    @Value("${envType}")
    private String envType;

    @Test
    @DisplayName("最普通的assume用法")
    void tryAssumeTrue() {
   
   
        assumeTrue("CI".equals(envType));

        log.info("CI环境才会打印的assumeTrue");
    }

    @Test
    @DisplayName("assume失败时带自定义错误信息")
    void tryAssumeTrueWithMessage() {
   
   
        // 第二个入参是Supplier实现,返回的内容用作跳过用例时的提示信息
        assumeTrue("CI".equals(envType),
                () -> "环境不匹配而跳过,当前环境:" + envType);

        log.info("CI环境才会打印的tryAssumeTrueWithMessage");
    }

    @Test
    @DisplayName("assume成功时执行指定逻辑")
    void tryAssumingThat() {
   
   
        // 第二个入参是Executable实现,
        // 当第一个参数为true时,执行第二个参数的execute方法
        assumingThat("CI".equals(envType),
                () -> {
   
   
                    log.info("这一行内容只有在CI环境才会打印");
                });

        log.info("无论什么环境都会打印的tryAssumingThat");
    }
}
  • 执行结果如下图,可见assume通过,所有信息都被打印出来了:
    在这里插入图片描述

  • 接下来把代码中的ActiveProfiles注解那一行注释掉,如下图红框:
    在这里插入图片描述

  • 执行结果如下,可见tryAssumingThat方法被标记为成功,不过从日志可见assumingThat的第二个入参executable没有被执行:
    在这里插入图片描述

  • 至此,Assumptions类的常用方法体验完成,接下来的章节会继续学习其他常用类;

欢迎关注博客园:程序员欣宸

学习路上,你不孤单,欣宸原创一路相伴...

相关文章
|
6月前
|
Java 测试技术 程序员
|
7月前
|
Java 测试技术 网络安全
JUnit5学习之三:Assertions类
断言是单元测试中最常用的测试手段,本文就来学习和操作常用的断言功能
JUnit5学习之三:Assertions类
|
8月前
|
Java 测试技术 API
Junit5单元测试框架原理和实践
Junit5单元测试框架原理和实践
134 1
|
JSON Java 测试技术
【高效编程】SpringMVC框架如何与Junit整合,看这个就够了
您好,我是码农飞哥,感谢您阅读本文!如果此文对您有所帮助,请毫不犹豫的一键三连吧!本文主要介绍在SpringMVC框架整合Junit框架进行单元测试。闲话少述,让我们直入主题。
90 0
|
XML 安全 Java
【Java技术指南】「TestNG专题」单元测试框架之TestNG使用教程指南(下)
【Java技术指南】「TestNG专题」单元测试框架之TestNG使用教程指南(下)
109 0
|
XML Java 测试技术
【Java技术指南】「TestNG专题」单元测试框架之TestNG使用教程指南(上)
【Java技术指南】「TestNG专题」单元测试框架之TestNG使用教程指南(上)
175 0
【Java技术指南】「TestNG专题」单元测试框架之TestNG使用教程指南(上)
|
测试技术
软件测试面试题:解释使用TestNG而不是JUnit框架的好处?
软件测试面试题:解释使用TestNG而不是JUnit框架的好处?
141 0
|
Java 测试技术 程序员
Java程序员必须要知道的单元测试框架Junit详解
作为一名java开发者,相信你或多或少的接触过单元测试,对于测试来讲它是一门能够区分专业开发人员与业余开发人员的重要学科,这篇文章将对java中最常见的一个单元测试框架junit进行一个梳理和讲解。如果你之前没接触过,那么就通过这篇文章进行一个学习。如果你是一个测试老手,我也希望这篇文章能够加深你的印象。
153 0
Java程序员必须要知道的单元测试框架Junit详解
Mockito框架实现学习之when(dummy)
Mockito框架实现学习之when(dummy)
113 0
Mockito框架实现学习之when(dummy)
|
Java 测试技术
使用Java JUnit框架里的@SuiteClasses注解管理测试用例
使用Java JUnit框架里的@SuiteClasses注解管理测试用例
218 0
使用Java JUnit框架里的@SuiteClasses注解管理测试用例

热门文章

最新文章

相关实验场景

更多