之前我拍着胸脯承诺要维护的我博客,因此才有了这篇文章。但是请忘记我的那些承诺,我今天要写的是关于
Mockito
,这是一个当你写单元测试时经常会用到的对象Mock框架。
这篇文章假设你已经知道了什么是
单元测试
以及为什么你要写单元测试。另外,我强烈建议你阅读
Martin
Fowler的这篇文章
。
常见的场景
有些时候我们需要测试有回调的函数,这意味着它们是异步执行的。这些方法测试起来并不那么容易,使用
Thread.sleep(milliseconds)
来等待它们执行完成只能说是一种蹩脚的实现,并且会让你的测试具有不确定性。那么我们如何来对异步函数进行测试呢?
Mockito
拯救了我们!
翠花,上示例
假设我们有一个实现了
DummyCallback
接口的
DummyCaller
类,在
DummyCaller
中有一个
doSomethingAsynchronously()
函数,该函数会调用
DummyCollaborator
类的
doSomethingAsynchronously(DummyCallback callback)
函数,在调用该函数时将这个callback参数设置为该
DummyCaller
对象。当
doSomethingAsynchronously(DummyCallback callback)
的任务在后台线程中执行完成之后就会回调这个callback。
还是直接看代码会更容易理解 :
DummyCallback接口 :
public interface DummyCallback {
public void onSuccess(List<String> result);
public void onFail(int code);
DummyCaller类 :
public class DummyCaller implements DummyCallback {
private final DummyCollaborator dummyCollaborator;
private List<String> result = new ArrayList<String>();
public DummyCaller(DummyCollaborator dummyCollaborator) {
this.dummyCollaborator = dummyCollaborator;
public void doSomethingAsynchronously() {
dummyCollaborator.doSomethingAsynchronously(this);
public List<String> getResult() {
return this.result;
@Override
public void onSuccess(List<String> result) {
this.result = result;
System.out.println("On success");
@Override
public void onFail(int code) {
System.out.println("On Fail");
真正的异步执行操作的DummyCollaborator类。
public class DummyCollaborator {
public static int ERROR_CODE = 1;
public DummyCollaborator() {
public void doSomethingAsynchronously (final DummyCallback callback) {
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(5000);
callback.onSuccess(Collections.EMPTY_LIST);
} catch (InterruptedException e) {
callback.onFail(ERROR_CODE);
e.printStackTrace();
}).start();
创建我们的测试类
我们有2种不同的选择来测试我们的异步函数,但是首先我们先创建一个DummyCollaboratorCallerTest测试类。
public class DummyCollaboratorCallerTest {
private DummyCaller dummyCaller;
@Mock
private DummyCollaborator mockDummyCollaborator;
@Captor
private ArgumentCaptor<DummyCallback> dummyCallbackArgumentCaptor;
@Before
public void setUp() {
MockitoAnnotations.initMocks(this);
dummyCaller = new DummyCaller(mockDummyCollaborator);
在setup函数中我们使用MockitoAnotations来初始化 Mock和ArgumentCaptor,我们暂时还不需要关心它们。
在这里我们需要关心的是在测试执行之前初始化了Mock对象和被测试的类,这些初始化代码都在setup中。记住,所有要测试的函数都要被测试两次。
让我们来看看下面的两种测试方案。
为我们的回调设置一个Anwser
这是我们使用doAnswer()来为一个函数进行打桩以测试异步函数的测试用例。这意味着我们需要理解返回一个回调(同步的),当被测试的方法被调用时我们生成了一个通用的anwser,这个回调会被执行。
最后,我们调用了doSomethingAsynchronously函数,并且验证了状态和交互结果。
@Test
public void testDoSomethingAsynchronouslyUsingDoAnswer() {
final List<String> results = Arrays.asList("One", "Two", "Three");
doAnswer(new Answer() {
@Override
public Object answer(InvocationOnMock invocation) throws Throwable {
((DummyCallback)invocation.getArguments()[0]).onSuccess(results);
return null;
}).when(mockDummyCollaborator).doSomethingAsynchronously(
any(DummyCallback.class));
dummyCaller.doSomethingAsynchronously();
verify(mockDummyCollaborator, times(1)).doSomethingAsynchronously(
any(DummyCallback.class));
assertThat(dummyCaller.getResult(), is(equalTo(results)));
[译者注 : 在doAnswer函数中当调用mockDummyCollaborator对象的doSomethingAsynchronously (final DummyCallback callback)函数时会触发Answer匿名内部类的answer(InvocationOnMock invocation)函数]。
使用ArgumentCaptor
第二种实现是使用ArgumentCaptor。在这里我们的callback是异步的: 我们通过ArgumentCaptor捕获传递到DummyCollaborator对象的DummyCallback回调。
最终,我们可以在测试函数级别进行所有验证,当我们想验证状态和交互结果时可以调用onSuccess()。
@Test
public void testDoSomethingAsynchronouslyUsingArgumentCaptor() {
dummyCaller.doSomethingAsynchronously();
final List<String> results = Arrays.asList("One", "Two", "Three");
verify(mockDummyCollaborator, times(1)).doSomethingAsynchronously(
dummyCallbackArgumentCaptor.capture());
assertThat(dummyCaller.getResult().isEmpty(), is(true));
dummyCallbackArgumentCaptor.getValue().onSuccess(results);
assertThat(dummyCaller.getResult(), is(equalTo(results)));
两种实现的主要的不同点是当使用DoAnswer()方案时我们创建了一个匿名内部类,并且将它的元素从invocation.getArguments()[n]转换到我们需要的类型,但是万一我们修改了我们的参数类型,那么这个测试就会’fail fast’。另一方面,当我们使用ArgumentCaptor时我们可能能够更精细的控制测试用例,因为我们能在测试用例中手动调用回调对象。
面对这两种方案,有时候我们不知道作何选择,但是不用担心,因为这是一个常见的问题。以我们的经验来看,同时使用这两种方案来测试异步函数会是一个更可靠的途径。
我希望这篇文章对你有用,另外,请记住,欢迎给这篇文章的反馈,或许还有更好的实现。当然,如果你有任何的疑问也可以联系我。
代码这里。这些代码都是关于Java和Android的,因为我们在几个月前做了一场相关的演讲。
我强烈建议你阅读Mockito文档以对这个框架有更深入的了解,这份文档非常清晰,并且有非常棒的示例!
Android系统的异步接口测试方法!基于Android的C/S移动应用中访问后端数据的场景是非常多的,异步接口测试主要是在单元测试完成的基础上检查接口级访问是否正确,主要保证对外请求的组装与发送是否符合后端的约定。现在项目的异步接口访问都遵循一个特定的访问模式:前台 基于Android的C/S移动应用中访问后端数据的场景是非常多的,异步接口测试主要是在单元测试完成的基础上检查接口级访问是否正确,主要保证对外请求的组装与发送是否符合后端的约定。现在项目的异步接口访问都遵循一个特定的访问模式:前台的Activity获取到触发事件后将接受到的参数传给一个异步任务,这些任务大都是AsyncTas
首先说一下怎样使用MockMvc进行单元测试
第一步是新建一个TestParent类,里面配置好公共的配置,如下所示。
package com.systoon.reportApi;
import com.google.gson.Gson;
import com.google.gson.GsonBuilder;
import com.hazelcast.aws.impl.Co
1. mockito是干什么的?Mock框架之一,其余的还有EasyMock,PowerMock等。
Mock说白了就是打桩(Stub)或则模拟,当你调用一个不好在测试中创建的对象时,
Mock框架为你模拟一个和真实对象类似的替身来完成相应的行为
就是利用他,我们可以创建一个傀儡,然后被mock的类要返回的数据我们都可以指定!
就像下面这样 :User user = mock(User.
平时写单测时,对于一些有限制或因当前环境无法访问的接口时,需要用到Mock来为目标接口添加自定义的实现,使其表现出我们希望表现的逻辑,从而不影响单元测试的实现。Mockito是常用的一个类库,使用也比较简单。使用分为注解的方式和直接创建对象的方式。
注解的方式
// 被注入的目标对象
@InjectMocks
private AimService aimService;
// 创建一个MockedService的一个mock对象
@Mock
private MockedService mockedSer
在示例代码中,使用JUnit4,版本为4.13。
1.1.1. 添加引用
参考“Gradle Dependency”( https://github.com/junit-team/junit4/wiki/Use-with-Gradle#gradle-dependency ),可通过以下方式在Gradle中引用JUnit 4.13。
'junit:junit:4.13'
1.1.2. @RunWith配置
参考“@R
本文中API文档部分,翻译自:Mockito
水平有限自己感觉很多地方表达的并不到位,但找不到更好的表达方式,如果您觉着有更好的表达方式,帮助我改进!
Mockito 是什么?Mockito 是一个开源的Java测试框架,它能够Mock对象、验证结果以及为测试用例打桩。
Mockito 有什么特点?Mockito 在运行时Mock对象,并且模拟被测试对象的行为,从而达到消除依赖的效果。
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;
import org.mockito.ArgumentCaptor;
import org.mockito.Mockito;
@SuppressWa...
Mockito 提供了一个应答接口, 允许 stubbing 具有泛型接口。语法//add the behavior to add numbers
when(calcService.add(20.0,10.0)).thenAnswer(new Answer<Double>() {
@Override
public Double answer(InvocationOnMock...