JUnit测试控制@Test执行顺序的三种方式小结

目录
  • JUnit测试控制@Test执行顺序
    • 第一种
    • 第二种(推荐)
    • 第三种
  • Junit测试方法保证执行顺序
    • 当使用默认排序时

JUnit测试控制@Test执行顺序

第一种

@FixMethodOrder(MethodSorters.JVM)

从上到下 执行@Test

第二种(推荐)

@FixMethodOrder(MethodSorters.NAME_ASCENDING) 

按方法名字顺序执行@Test

第三种

@FixMethodOrder(MethodSorters.DEFAULT)

默认方法,不可预期

Junit测试方法保证执行顺序

由于需要做自动化测试,所以需要比较完善的单元测试。但是又因为某些测试的执行依赖另外一个测试产生的结果,所以希望所写的test case按照自己希望的顺序来执行。

随后博主查阅资料发现了FixMethodOrder注解,可以有三种方式可以控制test执行顺序。

  /**
     * Sorts the test methods by the method name, in lexicographic order, with {@link Method#toString()} used as a tiebreaker
     */
    NAME_ASCENDING(MethodSorter.NAME_ASCENDING),
    /**
     * Leaves the test methods in the order returned by the JVM. Note that the order from the JVM may vary from run to run
     */
    JVM(null),
    /**
     * Sorts the test methods in a deterministic, but not predictable, order
     */
    DEFAULT(MethodSorter.DEFAULT);

大概上就是上面三种,很多大佬的博客上都对这几种有讲解以及示例,博主在这里就不啰嗦了,下面说一下我的一些疑问以及发现。

当使用默认排序时

@FixMethodOrder(MethodSorters.DEFAULT)
public class testDemo{

    @Test
    public void B(){
        System.out.println("b");
    }
    @Test
    public void C(){
        System.out.println("c");
    }
    @Test
    public void A(){
        System.out.println("a");
    }
    @Test
    public void AB(){
        System.out.println("ab");
    }
    @Test
    public void AC(){
        System.out.println("ac");
    }
    @Test
    public void A1(){
        System.out.println("a1");
    }
}

输出

a
b
c
a1
ab
ac

这只是博主众多测试结果中的一个,实际上与API中描述的“but not predictable”有所出入,执行的顺序是可预期的。

因为观察到,名字短的总排在前面,ascii码小的总在前面,所以博主猜测有可能顺序跟方法名字的字符串的hashcode有关的,于是加上hashcode方法输出之后,得到结果:

方法A:65
方法B:66
方法C:67
方法A1:2064
方法AB:2081
方法AC:2082

所以可以得出结论,当单元测试使用默认执行顺序的时候,测试方法执行的顺序是跟测试方法名字符串的hashcode大小线性相关。

Junit执行时应该是把所有的有@test注释的方法存到一个容器里,然后交由jvm去一一执行(博主还没来得及仔细去研读Junit的源码,这是本人的猜测)。那么问题来了,这一系列的方法是在同一个线程下还是多个线程一起执行的呢?

其实从测试的执行顺序可以控制不难猜出,多个测试方法是串行执行的,但是实践才是检验真理的唯一标准。

代码就不贴了,有兴趣的同学可以自己写一下看看,就是在第二顺位执行的方法那里让他休眠一下,观察是否也会阻塞第三个方法。

最终的结果也证明了猜想。

我现在看的还比较浅显,有时间的话会去研读Junit的底层源码。以上为个人经验,希望能给大家一个参考,也希望大家多多支持我们

(0)

相关推荐

  • 深入学习Java单元测试(Junit+Mock+代码覆盖率)

    前言 单元测试是编写测试代码,用来检测特定的.明确的.细颗粒的功能.单元测试并不一定保证程序功能是正确的,更不保证整体业务是准备的. 单元测试不仅仅用来保证当前代码的正确性,更重要的是用来保证代码修复.改进或重构之后的正确性. 一般来说,单元测试任务包括 1.接口功能测试:用来保证接口功能的正确性. 2.局部数据结构测试(不常用):用来保证接口中的数据结构是正确的 1.比如变量有无初始值 2.变量是否溢出 3.边界条件测试 1.变量没有赋值(即为NULL) 2.变量是数值(或字符) 1.主要边界

  • 详解Java单元测试之JUnit篇

    单元测试是编写测试代码,应该准确.快速地保证程序基本模块的正确性. JUnit是Java单元测试框架,已经在Eclipse中默认安装. JUnit4 JUnit4通过注解的方式来识别测试方法.目前支持的主要注解有: @BeforeClass 全局只会执行一次,而且是第一个运行 @Before 在测试方法运行之前运行 @Test 测试方法 @After 在测试方法运行之后允许 @AfterClass 全局只会执行一次,而且是最后一个运行 @Ignore 忽略此方法 下面基于Eclipse介绍JUn

  • 解决java junit单元测试@Test报错的问题

    在我们在myeclips里使用junit测试工具时有时会遇到错误,这是什么原因呢? 导致问题的原因通常有下面几个: (1)没有导入jar包 (2)导入jar包版本太低 (3)注意@Test要写在方法上面 如果不是几种问题,那便试试下面的解决方案: 1.在项目上点击右键,出现下图内容,选择properties 2.出现如下对话框,点击java build path,再选择add Library 3.之后如下图操作 4.选择junit4,点击finish,配置完毕. 以上这篇解决java junit

  • 详解Junit 测试之 Spring Test

    在做spring相关测试时比较麻烦,如果只用JUnit测试,需要没测有初始化一下applicationContext,效率比较底下,而且也有不足之处. 1.导致多次Spring容器初始化问题 根据JUnit测试方法的调用流程,每执行一个测试方法都会创建一个测试用例的实例并调用setUp()方法.由于一般情况下,我们在setUp()方法 中初始化Spring容器,这意味着如果测试用例有多少个测试方法,Spring容器就会被重复初始化多次.虽然初始化Spring容器的速度并不会太 慢,但由于可能会在

  • JUnit测试控制@Test执行顺序的三种方式小结

    目录 JUnit测试控制@Test执行顺序 第一种 第二种(推荐) 第三种 Junit测试方法保证执行顺序 当使用默认排序时 JUnit测试控制@Test执行顺序 第一种 @FixMethodOrder(MethodSorters.JVM) 从上到下 执行@Test 第二种(推荐) @FixMethodOrder(MethodSorters.NAME_ASCENDING) 按方法名字顺序执行@Test 第三种 @FixMethodOrder(MethodSorters.DEFAULT) 默认方法

  • Java实现指定线程执行顺序的三种方式示例

    本文实例讲述了Java实现指定线程执行顺序的三种方式.分享给大家供大家参考,具体如下: 方法一:通过共享对象锁加上可见变量来实现. public class MyService { private volatile int orderNum = 1; public synchronized void methodA() { try { while (orderNum != 1) { wait(); } for (int i = 0; i < 2; i++) { System.out.printl

  • springboot项目启动后执行方法的三种方式

    目录 1 方法 方法1:spring的ApplicationListener< ContextRefreshedEvent>接口 方法2:springboot的ApplicationRunner接口 方法3:springboot的CommandLineRunner接口 2 指定执行顺序 3 原理 springboot项目启动后执行方法,有三种实现方式. 1 方法 ApplicationListener< ContextRefreshedEvent> 不推荐 ApplicationL

  • Spring配置数据源的三种方式(小结)

    目录 一.前言 三.开发数据源的方式 方式1:手动输入 方式2:Properties配置文件 方式3:Spring配置数据源 四.总结 一.前言 今天学习了用spring配置Druid数据源的三种方式,整理了学习笔记,希望大家喜欢! 二.数据源的作用 数据源(连接池)是提高程序性能如出现的 事先实例化数据源,初始化部分连接资源 使用连接资源时从数据源中获取 使用完毕后将连接资源归还给数据源 常见的数据源:DBCP.C3P0.BoneCP.Druid等等,本文主要以Druid数据源为案例实现Spr

  • Maven打jar包的三种方式(小结)

    不包含依赖jar包 该方法打包的jar,不包含依赖的jar包,也没有指定入口类. <build> <plugins> <plugin> <!-- 指定项目编译时的java版本和编码方式 --> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.7.

  • MySQL复制表的三种方式(小结)

    复制表结构及其数据 下面这个语句会拷贝数据到新表中. 注意:这个语句其实只是把select语句的结果建一个表,所以新表不会有主键,索引. create table table_name_new as (select * from table_name_old); 只复制表结构 create table table_name_new as select * from table_name_old where 1=2; 或者 create table table_name_new like tabl

  • MySQL删除表的三种方式(小结)

    drop table drop 是直接删除表信息,速度最快,但是无法找回数据 例如删除 user 表: drop table user; truncate (table) truncate 是删除表数据,不删除表的结构,速度排第二,但不能与where一起使用 例如删除 user 表: truncate table user; delete from delete 是删除表中的数据,不删除表结构,速度最慢,但可以与where连用,可以删除指定的行 例如删除user表的所有数据 delete fro

  • mybatis-plus update更新操作的三种方式(小结)

    目录 1.@ 根据id更新 2.@ 条件构造器作为参数进行更新 3.@ lambda构造器 mybatisplus update语句为null时没有拼接上去 1.@ 根据id更新 User user = new User(); user.setUserId(1); user.setAge(29); userMapper.updateById(user); 2.@ 条件构造器作为参数进行更新 //把名字为rhb的用户年龄更新为18,其他属性不变 UpdateWrapper<User> updat

  • Shell 脚本自动输入密码的三种方式小结

    目录 方式一 方式二 方式三 注意,如果创建.sh文件后不可以执行,请执行sudo chmod 755 文件名.sh来修改权限. 方式一 使用 echo “密码” | (管道符) 使用场景: sudo 命令 在使用普通用户执行 root 命令时有时候会需要输入密码,并且在输入密码后一段时间不需要再次输入(但是不影响),这时候可以使用 echo "密码" | sudo 命令 比如我需要一键清空服务器,则可以创建一个clear.sh文件(假使我的密码是 123456): echo &quo

  • apache虚拟主机配置的三种方式(小结)

    目录 一.基于IP 二.基于主机名 三.基于端口 记事本打开httpd.conf文件 ,该文件在apache的目录下,如: D:\AppServ\Apache2.2\conf,修改如下两处: LoadModule vhost_alias_module modules/mod_vhost_alias.so //去掉前面的#,意思是启用apache的虚拟主机功能,第203行 Include conf/extra/httpd-vhosts.conf //去掉#的意思是从httpd-vhosts.con

随机推荐