首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

junit 5自定义参数化测试

junit 5是一个用于Java语言的测试框架,用于编写和运行单元测试。它提供了丰富的功能和API,使开发人员能够进行灵活且高效的测试。

自定义参数化测试是JUnit 5中的一个重要特性,它允许开发人员定义自己的测试参数并在测试中使用。通过参数化测试,我们可以对多组输入数据进行测试,以验证代码在不同情况下的行为。下面是自定义参数化测试的一般步骤:

  1. 创建一个带有@TestFactory注解的测试方法,该方法返回一个Stream、Iterable、Iterator、DynamicContainer或DynamicNode类型的对象。这将告诉JUnit 5该方法将生成一系列的测试参数。
  2. 在测试方法内部,使用@Test注解来标记每个具体的测试案例。可以将测试方法的参数声明为任何您希望使用的类型。
  3. 使用@MethodSource注解来指定一个静态方法或外部类,该方法或外部类将返回测试参数的来源。该方法或外部类必须返回一个Stream、Iterable或Iterator类型的对象。
  4. 编写逻辑代码,对每个测试参数执行实际的测试操作,并进行断言来验证预期的行为。
  5. 可选地,您还可以使用@DisplayName注解为测试方法提供自定义的显示名称。

下面是一个示例,演示如何在JUnit 5中进行自定义参数化测试:

代码语言:txt
复制
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.MethodSource;

import java.util.stream.Stream;

import static org.junit.jupiter.api.Assertions.assertEquals;

public class CustomParameterizedTest {

    // 定义一个静态方法来返回测试参数
    static Stream<String> stringProvider() {
        return Stream.of("apple", "banana", "orange");
    }

    // 使用自定义参数进行测试
    @ParameterizedTest
    @MethodSource("stringProvider")
    @DisplayName("测试字符串的长度")
    void testStringLength(String input) {
        assertEquals(5, input.length());
    }

    // 普通的单元测试方法
    @Test
    void testAddition() {
        int result = 2 + 3;
        assertEquals(5, result);
    }
}

在上面的示例中,我们定义了一个静态方法stringProvider()来返回测试参数。然后,我们使用@ParameterizedTest注解标记了testStringLength()方法,并使用@MethodSource注解将stringProvider()方法指定为参数来源。

testStringLength()方法中,我们对每个测试参数执行了测试操作,并通过断言来验证预期的结果。此外,我们还使用@DisplayName注解为测试方法提供了一个自定义的显示名称。

除了JUnit 5自带的参数化测试功能外,腾讯云也提供了一些相关的产品和服务,可以帮助开发人员在云环境中进行测试和部署。例如,腾讯云的云服务器、云原生应用平台、云函数等产品可以提供灵活的计算资源和环境,以支持测试和部署的需求。您可以访问腾讯云官方网站了解更多关于这些产品的详细信息。

注意:本答案中没有提及亚马逊AWS、Azure、阿里云、华为云、天翼云、GoDaddy、Namecheap、Google等流行的云计算品牌商。如需了解更多相关信息,请自行搜索或访问官方网站。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

  • 软件测试|Junit5 实现参数和数据驱动

    图片登录:不同的用户名,不同的密码,不同的组合都需要做登录场景的测试,正常的排列组合下可能会产生多个用例搜索:不同的搜索条件产生不同的搜索结果,搜索也是常见的测试项,单个搜索参数或者多种搜索参数的组合;...参数:我们在写自动化用例的时候会有很多方法,一般我们都会把数据通过参数来传递给方法,而不会直接在方法中写“死”,所以方法之间的数据传递都是通过参数来进行,利用参数进行数据与变量的对应;比如我们的登录账号密码设置在参数中...- - 洗衣液- - 帽子- - 手套总结下来:在执行测试工作过程中,有很多过程是需要动态变化的,如果每一次的变化都需要编码部署,那么整个执行的流程就会边长;对于业务测试工程师来说,维护自动代码有一定的门槛...,主要也是方便业务测试维护,降低维护门槛和代码修改部署出错的风险;修改配置文件,整个业务行为和抽象是不用改变的,当然,在UI自动中配合PO一起使用会“风味更佳”。...手工录制测试步骤,直接生成代码比较困难,可以生成步骤的配置文件,让代码去读配置文件,完成自动的回放;(此方面本人暂时仅了解过,还未实践落地,理论上是可以实现的。)

    1.3K40

    JUnit5参数测试扩展3案例

    参数测试方面,JUnit5提供了较为丰富的数据源,如@ValueSource,支持提供int、float等基本类型以及String和Class等作为参数,@CsvSource可以提供CSV格式的数据...除了上述由JUnit5提供的数据源之外,JUnit也接受自定义数据源来进行参数测试。...使用基于JUnit5自定义数据源的开源项目junit-pioneer就支持这样的测试场景。...junit-pioneer正是通过RangeSourceArgumentsProvider来实现这一接口,可以实现了对这种规定起止点后按步距增长的参数测试场景。...案例3-@JsonSource 除了@CsvSource和@CsvFileSource来读取CSV格式的入参之外,在工作中也可能希望是以JSON格式的数据来实施参数测试,毕竟JSON类型的数据已经成为了系统接口之间交换数据的主流方式

    93430

    JUnit5学习之七:参数测试(Parameterized Tests)进阶

    系列旨在通过实战提升SpringBoot环境下的单元测试技能,一共八篇文章,链接如下: 基本操作 Assumptions类 Assertions类 按条件执行 标签(Tag)和自定义注解 参数测试(Parameterized...Tests)基础 参数测试(Parameterized Tests)进阶 综合进阶(终篇) 本篇概览 本文是《JUnit5学习》系列的第七篇,前文咱们对JUnit5参数测试(Parameterized...Tests)有了基本了解,可以使用各种数据源控制测试方法多次执行,今天要在此基础上更加深入,掌握参数测试的一些高级功能,解决实际问题; 本文由以下章节组成: 自定义数据源 参数转换 多字段聚合 多字段转对象...参数测试的数据源和测试方法入参的数据类型必须要保持一致吗?...的参数测试(Parameterized)相关的知识点已经学习和实战完成了,掌握了这么强大的参数输入技术,咱们的单元测试的代码覆盖率和场景范围又可以进一步提升了;

    97930

    JUnit5学习之六:参数测试(Parameterized Tests)基础

    系列旨在通过实战提升SpringBoot环境下的单元测试技能,一共八篇文章,链接如下: 基本操作 Assumptions类 Assertions类 按条件执行 标签(Tag)和自定义注解 参数测试(Parameterized...Tests)基础 参数测试(Parameterized Tests)进阶 综合进阶(终篇) 本篇概览 本文是《JUnit5学习》系列的第六篇,一起来实战强大参数测试(Parameterized Tests...),即多次执行同一个测试方法,每次使用不同的参数; 由于参数测试功能强大,内容也比前几篇的知识点多,为了方便大家阅读和实践,这里分为《基础》和《进阶》两篇来介绍,本篇以学习参数测试(Parameterized...=candidate); } } 执行该测试类,结果如下图: 从上图可见执行参数测试需要两步:首先用@ParameterizedTest取代@Test,表名此方法要执行参数测试...,显得更加简洁一些: 期待《进阶》篇 至此,咱们队JUnit5参数测试(Parameterized)有了初步的了解,可以通过各种数据源注解给测试方法制造更多的参数,但仅掌握这些还是不够的,依然有一些问题待解决

    90620

    如何用Junit5玩出参数测试的新花样?

    简介 这是之前一篇文章《用junit5编写一个类ZeroCode的测试框架》的续集。主要将在之前工作的基础上,围绕参数测试展开。...框架主要设计点: 一个用例是一个测试文件 一个用例集是一个目录 用例全部在文件中呈现,不需要写代码 主要使用的是 Junit5提供的@ParameterizedTest 引入参数 为了能使用Junit5...中重新设计的参数测试解决方案,需要额外在pom.xml中引入junit-jupiter-params org.junit.jupiter</groupId...在一般的参数测试介绍中,通常的方案是将一个文件作为数据源,如一个单一的csv文件,然后其中的某一行作为一个用例。而在我们的方案中,我们需要将整个给定目录中的csv文件作为测试用例集进行遍历执行。...,并依次作为testCase入参来执行sampleTest方法,从而实现所谓的参数测试

    93430

    如何用Junit5玩出参数测试的新花样?

    简介 这是之前一篇文章《用junit5编写一个类ZeroCode的测试框架》的续集。主要将在之前工作的基础上,围绕参数测试展开。...框架主要设计点: 一个用例是一个测试文件 一个用例集是一个目录 用例全部在文件中呈现,不需要写代码 主要使用的是 Junit5提供的@ParameterizedTest 引入参数 为了能使用Junit5...中重新设计的参数测试解决方案,需要额外在pom.xml中引入junit-jupiter-params org.junit.jupiter</groupId...在一般的参数测试介绍中,通常的方案是将一个文件作为数据源,如一个单一的csv文件,然后其中的某一行作为一个用例。而在我们的方案中,我们需要将整个给定目录中的csv文件作为测试用例集进行遍历执行。...,并依次作为testCase入参来执行sampleTest方法,从而实现所谓的参数测试

    1.5K20

    Junit5系列-Junit5中@DisplayName自定义名称

    目录 简介 demo分析 源码分析 简介 测试类和测试方法可以声明自定义显示名称 ,可以包含空格,特殊字符,甚至是表情符号 ,自定义名称将由测试运行者和测试报告显示。...上述功能的实现使用的就是junit5中的@DisplayName注解 demo分析 测试代码: import org.junit.jupiter.api.DisplayName; import org.junit.jupiter.api.Test...,可以看到自定义名称是可以重复的: ?...@Retention说明在源文件、class文件、运行时都存在该注解 元注解@Documented说明此注解将包含在javadoc说明中 @API 说明了该注解的现状,该注解是稳定的且从5.0添加的 参数...:String value(); 赋值我们的自定义名称,没有默认值所以必须要赋值,否则编译器会报错。

    3.6K30

    Junit5系列-Junit5中DisabledCondition条件测试执行

    目录 简介 规定操作系统条件 规定Java 运行环境条件 规定系统属性条件 规定环境变量条件 规定脚本依赖条件 Junit5中提供了许多可以基于操作系统、系统变量、环境变量甚至可以基于脚本去进行启动或禁止测试方法的执行...简介 JUnit Jupiter中的ExecutionCondition扩展API允许开发人员以编程方式启用或禁用容器或测试。...除了@Disabled之外,JUnit Jupiter还支持 org.junit.jupiter.api.condition类中的其他几个注解去允许开发人员以注解声明的方式启用或禁用容器和测试的条件包。...下面介绍的所有注解也可以作为元注解使用,以便用来创建自定义注解。 例如,演示中的@TestOnMac注解就是将@Test和@EnabledOnOs结合在一个单独的、可重用的注解中。...4 junitDisplayName String 测试或者容器的展示名称 5 junitTags Set 测试或者容器的所有标签信息 6 junitUniqueId String 测试或者容器的唯一标识

    1.5K40

    Junit5 + YAML 轻松实现参数和数据驱动,让 App 自动测试更高效(一)

    参数:我们在写自动化用例的时候会有很多方法,一般我们都会把数据通过参数来传递给方法,而不会直接在方法中写“死”,所以方法之间的数据传递都是通过参数来进行,利用参数进行数据与变量的对应;比如我们的登录账号密码设置在参数中...sendKeys(inputPassword,password); click(loginBtn); return new MainPage(); } 数据驱动:将参数中的数据来源变成从外部读取...- - 洗衣液 - - 帽子 - - 手套 总结下来: 在执行测试工作过程中,有很多过程是需要动态变化的,如果每一次的变化都需要编码部署,那么整个执行的流程就会边长; 对于业务测试工程师来说,维护自动代码有一定的门槛...,主要也是方便业务测试维护,降低维护门槛和代码修改部署出错的风险;修改配置文件,整个业务行为和抽象是不用改变的,当然,在UI自动中配合PO一起使用会“风味更佳”。...手工录制测试步骤,直接生成代码比较困难,可以生成步骤的配置文件,让代码去读配置文件,完成自动的回放;(此方面本人暂时仅了解过,还未实践落地,理论上是可以实现的。)

    1.2K30
    领券