发布时间:2023-08-18 14:30
比如你现在想要测试一个方法是否是正常的,但是这个方法中有很多调用数据库的代码,那么我们就可以在每个调用数据库的地方打桩,模拟一下访问完数据库之后的返回值,这样我们就可以在测试的时候避免访问数据库了,可以非常高效地完成我们的单元测试,已达到验证我们写的方法到底对不对的目的。
先试想一个这样的场景,如果想要模拟一个人被车撞之后,会出现什么样的运动轨迹,那我们要做实验的时候肯定是不能用一个活生生的人做实验的对不对?
我们的Mock模拟对象也是一样的,因为真实对象由于一些原因很难被拿来直接做测试,所以我们就必须要模拟一个和真实对象一样的对象,那这个模拟的对象做测试,而Mock就是用来模拟对象的。
那么对象在什么时候是不方便被直接拿来做实验的啊?你比如:
我们的Mockito单元测试需要配合Junit单元测试一起使用,因此首先我们需要导入这两个依赖,如下图:
<dependencies>
<dependency>
<groupId>org.mockitogroupId>
<artifactId>mockito-allartifactId>
<version>1.9.5version>
<scope>testscope>
dependency>
<dependency>
<groupId>junitgroupId>
<artifactId>junitartifactId>
<version>4.11version>
<scope>testscope>
dependency>
dependencies>
如果我们想要测试某个类中的某个方法是否可以执行,我们不用直接调用这个类的这个方法,我们可以模拟一下这个类,让模拟的对象调用这个方法,然后再去检验一下这个模拟对象是否成功的调用到了这个方法,只要这个模拟对象成功调用到了这个方法,那么就说明,我们真实类中的这个方法是可以被成功执行的。这就是使用mockito来进行某个类的单元测试,如下图:
/**
* 通过mock模拟一个对象,然后检验这个对象的某个方法是否可以执行
* */
@Test
public void test1(){
//模拟创建一个List对象
List mock = mock(List.class);
//使用mock模拟出来的List对象,让这个对象添加一个元素1,(我们其实是为了验证List类中的add方法是否正常)
mock.add(1);
//验证模拟的对象List的add(1)方法是否执行,如果正常发生了,说明List类中的add(1)方法是正常的。这样我们的单元测试就算通过,
//verify()的作用主要是检验我们模拟出来的这个对象中的方法是否成功执行,如果成功执行控制台什么信息都没有,如果没有成功
//执行,控制台会报错误信息
verify(mock).add(1);
}
我们在测试一个控制器中的方法的时候,这个控制器中肯定是有一些方法是需要访问数据库的,但是我们自己在进行单元测试的时候,其实不必访问数据库,我们只需要知道访问数据库之后得到的这个值是什么,所以我们就可以使用Mock来模拟出访问数据库的方法返回的值,下面的这个例子就是我们自己给某个类中的方法直接指定一个返回值,如下图:
/**
* 模拟对象中的某个方法,给这个方法指定一个返回值,那么我们再执行这个模拟对象的方法的时候,返回的值就不再是真实
* 对象返回的值,而应该是我们自己设置的返回值。
*
* 比如我们这里有一个Iterator迭代器,原本调用迭代器对象的next()方法之后返回的值是集合中的下一个元素,我们这里来模拟
* 这个方法的返回值,模拟的是第一次调用next()方法返回值是"hello",第二次调用next()方法返回值是"world",第三次以及往后调用
* next()方法返回值是"abc"
*
* 使用到了when(),thenReturn()方法,第一个thenReturn()代表第一次执行iterator.next()方法的返回值是"hello",
* 第二个thenReturn()代表第二次执行iterator.next()方法的返回值是"world",
* 第三个thenReturn()代表第三次即以后执行iterator.next()方法的返回值都是"abc"
*
* 还是用到了assertEquals(猜想值,变量)断言方法
* */
@Test
public void test2(){
//使用mock模拟出一个Iterator类
Iterator iterator = mock(Iterator.class);
//自己设置迭代器对象方法next()的返回值
when(iterator.next()).thenReturn("hello").thenReturn("world").thenReturn("abc");
//使用mock模拟的iterator对象,去看看iterator调用next()方法之后的返回值是否是我们想的那样
String result = iterator.next() + " " + iterator.next() + " " + iterator.next()+" "+iterator.next();
//使用断言验证猜想的结果是否正确
assertEquals("hello world abc abc",result);
}
/**
* 使用Mock模拟对象,规定某个方法要抛出一个异常
* */
@Test(expected = IOException.class)
public void test3() throws IOException {
OutputStream outputStream = mock(OutputStream.class);
//我们自己规定当执行OutputStream对象的close()方法的时候,会主动的抛出一个IOException异常
doThrow(new IOException()).when(outputStream).close();
outputStream.close();
}
/**
* 模拟类中的某个方法(加上对应的参数)调用的次数
*
* times(次数)表示调用几次
* never()表示从没有调用过
* atLeastOnce()表示至少调用多少1次
* atLeast(次数)表示至少调用n次
* atMost(次数)表示最多调用n次
* */
@Test
public void test5(){
List list = mock(List.class);
list.add(1);
list.add(2);
list.add(2);
list.add(3);
list.add(3);
list.add(3);
//验证是否被调用一次,等效于下面的times(1)
verify(list).add(1);
verify(list,times(1)).add(1);
//验证是否被调用2次
verify(list,times(2)).add(2);
//验证是否被调用3次
verify(list,times(3)).add(3);
//验证是否从未被调用过
verify(list,never()).add(4);
//验证至少调用一次
verify(list,atLeastOnce()).add(1);
//验证至少调用2次
verify(list,atLeast(2)).add(2);
//验证至多调用3次
verify(list,atMost(3)).add(3);
}
/**
* @Date 2021/11/10 15:47
* @Author 望轩
*
* 使用@Mock注解生成一个模拟对象,注意这样的话必须要在加上一个注解@RunWith(MockitoJUnitRunner.class),
* 要不然的话应用到的mockList或者是iterator会是null值
*/
@RunWith(MockitoJUnitRunner.class)
public class MockitoTest2 {
@Mock
private List mockList;
@Mock
private Iterator iterator;
@Test
public void test1(){
mockList.add(1);
verify(mockList).add(1);
}
@Test
public void test2(){
iterator.next();
verify(iterator).next();
}
}
我们打桩其实是在真实方法的内部对应的位置进行打桩的,如果真实方法的对应的真实代码不会执行,那么我们在单测的时候,打桩就无效。你比如说,我们现在想要在真实方法的if判断体里面打一个桩,如果这个if判断体一直不成立,我们我们在单元测试方法中打的桩就不会替换掉真实代码中的具体位置。解释过程如下图:
下图这个异常可以通过上图来解答:
打桩其实就是在真实代码的地方用一个模拟方法代替,然后真实方法执行到这个地方的时候,它的返回值是我们模拟的返回值。when().thenReturn(),用这句代码我们可以自己给某个方法设定返回值,这就叫做打桩。
在什么时候需要打桩呢?如果我们想要自测的方法有返回值,我们需要打桩,如下图:
什么时候不需要打桩呢?当我们想要测试的方法没有返回值的时候,这个时候我们就不用打桩了,但是我们需要检测一下这个方法是否执行了,如下图:
比如现在有一个需求,就是我们在增加期间的时候,数据库中不能存在这个期间,要不然就增加失败,在真实方法中的代码表现如下图:
单测的代码如下图:
我们提示的异常信息上面还有一个LocalDateTime日期类,但是我们之前明明已经把我们的LocalDateTime日期类改成了Date日期类,那么还报我们在项目中使用了LocalDateTime日期类,这是为什么呢?可能是因为我们的工程没有重新编译,我们现在使用的还是之间没有改成Date的字节码,所以才会出现上面的异常。这个时候我们要做的就是把Parent父工程重新clean一下,然后在重新运行我们的单元测试方法。
clean完parent父工程之后,重新测试单测方法,执行成功。
首先我们的单测代码都是写在deploy工程的test包下面的,如下图:
我们写的单测类必须要继承一个类并且也要使用到一个注解,如下图:
比如我们举一个例子,我们举一个测试真实方法的例子。
首先来看一下我们真实的方法是什么样子的,如下图:
然后我们再来看一下我们单测的方法是什么样子的,如下图:
如下图:
总之就是,我们单测方法里面的模拟返回值必须要符合真实方法中的逻辑,要不然真实方法会报异常,我们的单测就不能通过。
有的时候真实方法中也需要用到我们的单测方法中模拟出来的返回值,如下图:
assert关键字可以终止程序正常运行,assert关键字的作用是断言,如果它发现后面是true,那么程序可以正常运行,但是如果它发现后面是false,那么它会主动抛出一个异常并终止正在运行的程序。
打桩的时候,如果给一个参数用了匹配器any(),那么其它的参数也必须都用any()匹配器,如下图:
首先为什么会有单测?主要是因为我们程序不想要访问数据库,所以我们就可以模拟一下访问数据库的操作。
单测的时候,调用我们要测试的方法的时候,一定要有实际的参数,如下图:
单测的时候,如果我们想要打桩的地方,它的返回值会被其它地方用到,并且它的返回值的某个属性如果没有或者格式不正确还会出现异常,那么这个时候,我们就一定要打桩模拟一个返回值,如下图:
如果打桩的时候不需要返回值,我们可以这样写,如下图:
不需要返回值,也可以使用doNothing(),如下图:
在进行单测的时候,先把我们这个方法所用到的数据库里面的数据写在一张纸上面,成功写下所有的模拟数据之后,再进行单测代码的编写。
在进行单测的时候,首先要知道这个方法主要是干什么的,比如我做的一个单测导入功能,首先我需要先清楚导入这个方法需要从数据库里面查询的数据格式。比如这里从数据库里查询的数据格式有部门树,和科目树,所以我们就模拟了两个部门对象,一个是一级部门,另外一个是二级部门,如下图:
然后打桩的时候直接返回这些模拟数据,如下图:
然后模拟了三个科目,分别是一级,二级,三级科目,并且在打桩的时候直接返回模拟数据,如下图:
并且如果这些模拟对象存在某种逻辑关系我们也要指明,比如在部门树里,一级部门就必须是二级部门的父级如下图:
在科目树里我们也指明了它们的关系,如下图:
这里是导入方法importFromExcel()里面调用了getAllBudgetReportCategories(Long annualId),我们只需要关心这个方法需要返回什么数据给importFromExcel()方法才算合理就行了,最后把这个合理数据模拟出来。所以这个方法的前两个地方打桩的时候,它返回的模拟数据不用太多规范只要能保证后面能不报异常就行,但是最后一个打桩的地方,它返回的模拟数据必须要合理,因为它返回的模拟数据会被importFromExcel()后面的部分用到,所以所有打桩的模拟数据之间必须要相互匹配。
一个方法中如果有多个节点需要打桩,我们只需要关心最后一个需要打桩的地方它的模拟数据,至于前面需要打桩的地方,它返回的模拟数据我们不需要关心,但是要保证前面的这个打桩后的模拟数据能够保证后面能成功运行就行了。我们想一下我们调用这个方法的时候,想要让这个方法返回什么数据,那么在打桩的时候我们就模拟返回什么数据,如下图:
我们可以使用静态模拟类的方式进行打桩,如下图:
注意:
如果工具类中的静态方法没有返回值,我们直接模拟一下工具类就行了,不需要对静态方法进行打桩,如下图:
那像我们这种返回值不会被后面用到的方法,在打桩的时候应该如何打桩呢?像这种方法不用打桩,我们直接去掉就行了。如下图:
如果原本的方法中的访问数据库的方法后面不需要用到它的返回值,那么我们可以不用打桩,什么都不用写,如下图:
打桩方法如下图:
对于原始的那个的哪个方法里面的所有的属性,我们都需要Mock模拟一下,因为你如果不模拟的话,那么测试这个方法执行到这个对象的地方,就会出现空指针异常,因为我们单测的时候,所有的对象都需要用模拟对象,如果你没有用模拟对象,就会出现空指针异常,如下图:
在单测方法所对应的那个类中,没有引入模拟对象EnvUtils,如下图:
然后对应的真实方法的地方,牵涉到envUtils对象的地方就会报空指针异常,如下图:
第一步打开mvn,如下图:
第二步输入mvn命令,如下图:
mvn clean test org.jacoco:jacoco-maven-plugin:0.8.0:prepare-agent install -Dmaven.test.failure.ignore=true
第三步:执行之后去deploy->target->site->jacoco-resources->index.html查看,在浏览器打开index.html页面,可以查看覆盖率。
要想要使用jacoco在线生成覆盖率,首先需要在pom.xml文件中引入jacoco插件,如下图:
<build>
<plugins>
<plugin>
<groupId>org.jacocogroupId>
<artifactId>jacoco-maven-pluginartifactId>
<version>0.8.0version>
<executions>
<execution>
<goals>
<goal>prepare-agentgoal>
goals>
execution>
<execution>
<id>reportid>
<phase>testphase>
<goals>
<goal>report-aggregategoal>
goals>
execution>
executions>
<configuration>
<propertyName>surefireArgLinepropertyName>
<excludes>
<exclude>**/model/*exclude>
<exclude>**/model/**exclude>
<exclude>**/dto/*exclude>
<exclude>**/dal/**exclude>
<exclude>**/copy/*exclude>
<exclude>**/util/*exclude>
<exclude>**/utils/**exclude>
<exclude>**/task/**exclude>
<exclude>**/constant/*exclude>
<exclude>**/*Config.classexclude>
<exclude>**/*Util.classexclude>
<exclude>**/*Exception.classexclude>
<exclude>**/*Enum.classexclude>
<exclude>com/timevale/budget/service/mq/MqConsumer.classexclude>
<exclude>com/timevale/budget/service/impl/ExcelServiceImpl.classexclude>
excludes>
configuration>
plugin>
plugins>
build>
把build标签写在denpendencies的下面就行了。
使用mockito写单测的时候,我们需要先引入mockito的坐标,如下图:
<dependency>
<groupId>org.mockitogroupId>
<artifactId>mockito-coreartifactId>
<version>3.6.28version>
<scope>testscope>
dependency>
<dependency>
<groupId>org.mockitogroupId>
<artifactId>mockito-inlineartifactId>
<version>3.11.2version>
<scope>testscope>
dependency>
注意一定要在配置文件中对自己写的单元测试类进行配置,否则的话,在index.html页面看不到我们单元测试类的覆盖率。
在maven工具中,输入下面的命令:
mvn clean test org.jacoco:jacoco-maven-plugin:0.8.0:prepare-agent install -Dmaven.test.failure.ignore=true
结果如下图:
我这里的工程是buget工程,这个工程存放在我本地的电脑中了,特别注意:存放这个工程的目录不能含有中文,必须要是全英文,要不然的话,在浏览器中打开index.html文件的时候,会显示覆盖率为0。
以后只要是本地电脑存放工程的目录,都必须要是全英文的,防止出现一些奇怪的错误,记住这个规范,如下图:
单测一个方法的时候,首先去分析这个方法需要使用那些模拟数据,然后在分析有哪几个地方需要进行打桩,我们直接在打桩的时候返回这些模拟数据就行了,如下图:
当我们打桩的时候,构造器会先执行,然后再打桩,所以我们一定要先模拟一下构造器,不让它执行,如下图:
上图中我们就可以把左边的那个打桩给去掉,单元测试仍然能够执行成功。
对于我们模拟的类,一定要对它进行close,不管我们模拟的是工具类,还是模拟的其它的什么类,在执行完真实的方法之后,一定都要close一下,否则的话后面再模拟这个类的时候会出错。一定要在执行完真正的业务方法之后再进行close,否则的话,在没有执行真正的业务方法之前进行close方法的调用就相当于是没有模拟。
如下图:
redis配置mysql缓存_redis作为mysql的缓存服务器(读写分离) (转)
python sklearn 画出决策树并保存为PDF的实现过程
Swig超详细入门教程(Java调用C/C++, CMake)——更新于2021.12
java 常用 APL(系统相关类 ,Object类 和包装类详解)
软件随想录(local.joelonsoftware.com/wiki)-2000年06月03日 策略书之三:让我换回去! - Strategy Letter III: Let Me Go Back!