never()函数

public static VerificationMode never()

相当于times(0),可参见 times(int)
验证交互没有发生. 例如:

如果你想验证mock之间没有交互,可以使用verifyZeroInteractions(Object...) 或者 verifyNoMoreInteractions(Object...) 这两个方法

具体例子可以参考Javadoc中的Mockito

Returns:

  • 验证模式

only()函数

public static VerificationMode only()

如果当前mock的方法只被调用一次,则允许被检验。例如:

可以参考verifyNoMoreInteractions(Object...)方法

具体例子可以参考Javadoc中的Mockito

Returns:

  • verification mode

reset(T… mocks)函数

public static <T> void reset(T... mocks)

聪明的程序员很少会使用这个方法,因为他们知道使用这个方法意味着这个测试写的很low.通常情况下,你不需要重置你的mocks,你仅仅需要为你的测试方法创建新的mocks就可以了。

你可以考虑写一些简单的、精悍的、聚焦的测试方法来代替reset()这个方法。当你在在测试方法的中间部分用到reset()这个方法时,说明你的测试方法太庞大了。

请遵循以下关于测试方法的建议:请保证你的测试方法在一个动作中短小、精悍、聚焦。在mockito的邮件列表中有很多关于这方面的主题讨论。

我们添加reset()方法的唯一原因是使得注入容器的mocks得以有效的运行,具体可以参看issue 55 here or FAQ here

不要败坏了你在程序员界的名声,测试方法中间的reset()方法是代码中的害群之马(这意味着你的这个测试方法太多)

Type Parameters:

  • T – mocks的类型

Parameters:

  • 被重置的mocks

spy(Class classToSpy)函数

@Incubating
public static <T> T spy(Class<T> classToSpy)

请参考关于类spy的文档,过渡使用spy会导致代码变的非常糟糕。

相比与原来的spy(对象),这种方法可以在类的基础上创建一个spy,而不是一个对象。有时你可以很方便基于类创建spy而避免提供一个spy对象的实例。

因为他们不能被实例化,所以这个对于抽象类的监控非常有用。参见mocksettings.useconstructor()

例如:

Type Parameters:

  • T – spy的类型

Parameters:

  • spy的类

Returns:

  • a spy of the provided class

Since:

  • 1.10.12

stub(T methodCall)函数

public static <T> DeprecatedOngoingStubbing<T> stub(T methodCall)

对一个方法打桩会返回结果值或者错误异常,例如:

一些用户有点混乱、混淆,是因为相比于’stub()’,’when(Object)’更加被推荐

当对一个返回值为空且抛出异常的方法打测试桩:doThrow(Throwable)测试桩会被重写:例如通常测试桩会设置为常用固定设置,但测试方法可以重写它。切记重写测试桩是一种非常不推荐的写法,因为这样做会导致非常多的测试桩。

一旦这个方法打过桩,无论这个方法被调用多少次,这个方法会一直返回这个测试桩的值。

当你对相同的方法调用相同的参数打测试桩很多次,最后面的测试桩则非常重要

尽管我们可以去验证对测试桩的调用,但通常它都是多余的。比如说你对foo.bar()打测试桩。如果你比较关心的是当某些情况foo.bar()中断了(经常在verify()方法执行之前),此时会返回什么。如果你的代码不关心是get(0)会返回什么那么它就不应该被添加测试桩。如果你还不确定?看这里

Parameters:

  • methodCall – 调用的方法

Returns:

  • DeprecatedOngoingStubbing 对象是用来设置测试桩的值或者异常的

stubVoid(T mock)函数

public static <T> VoidMethodStubbable<T> stubVoid(T mock)

已废弃.使用doThrow(Throwable)方法代替去打空测试桩

doThrow()之所以取代了stubVoid()方法,是因为它增加了和它的兄弟方法doAnswer()的可读性以及一致性

具体例子可以参考Javadoc中的Mockito

Parameters:

  • mock – to stub

Returns:

  • stubbable object that allows stubbing with throwable

timesout(long millis)函数

public static VerificationWithTimeout timeout(long millis)

允许验证时使用timeout。它会在指定的时间后触发你所期望的动作,而不是立即失败,也许这个对并发条件下的测试非常有用。它和after()是有所有不同的,因为after()会等候一个完整的时期,除非最终的测试结果很快就出来了(例如:当never()失败了), 然而当验证通过时,timeout()会快速地停止,当你使用times(2)时会产生不同的行为。例如,当先通过然后失败,在这种情况下,timeout将会当time(2)通过时迅速通过,然而after()将会一直运行直到times(2)失败,然后它也一同失败。

这个功能看起来应该极少使用,但在多线程的系统的测试中,这是一个很好的方式

目前尚未实现按照顺序去验证

具体例子可以参考Javadoc中的Mockito

Parameters:

  • millis – – 时间长度(单位:毫秒)

Returns:

  • 验证模式

time(int wantedNumberOfInvocations)函数

public static VerificationMode times(int wantedNumberOfInvocations)

允许验证调用方法的精确次数,例如:

具体例子可以参考Javadoc中的Mockito

Parameters:

  • wantedNumberOfInvocations – 希望调用的次数

Returns:

  • 验证模式

validateMockitoUsage()函数

public static void validateMockitoUsage()

首页,无论遇到任何问题,我都鼓励你去阅读the Mockito问答集:http://groups.google.com/group/mockito,你也可以在mockito邮件列表提问http://groups.google.com/group/mockito.

validateMockitoUsage()会明确地检验framework的状态以用来检查Mockito是否有效使用。但是,这个功能是可选的,因为‘Mockito`会使这个用法一直有效,不过有一个问题请继续读下去。

错误示例:

如果你错误的使用了Mockito,这样将会抛出异常,这样你就会知道你的测试是否写的正确。你要清楚当你使用这个框架时,Mockito会接下来的所有时刻开始验证(例如:下一次你验证、打测试桩、调用mock等)。尽管在下一次测试中可能会抛出异常,但这个异常消息包含了一个完整栈踪迹路径以及这个错误的位置。此时你可以点击并找到这个Mockito使用错误的地方。

有时,你可能想知道这个框架的使用方法。比如,一个用户想将validateMockitoUsage()放在它的@after方法中,为了能快速地知道它使用Mockito时哪里错了。如果没有这个,它使用这个框架时将不能那么迅速地知道哪里使用错了。另外在@after中使用validateMockitoUsage()比较好的一点是jUnit runner以及Junit rule中的测试方法在有错误时也会失败,然而普通的next-time验证可能会在下一次测试方法中才失败。但是尽管Junit可能对下一次测试报告显示红色,但不要担心,这个异常消息包含了一个完整栈踪迹路径以及这个错误的位置。此时你可以点击并找到这个Mockito使用错误的地方。

同样在runner中:MockitoJUnitRunner and ruleMockitoRule在每次测试方法之后运行validateMockitoUsage()

一定要牢记通常你不需要’validateMockitoUsage()’和框架验证,因为基于next-time触发的应该已经足够,主要是因为可以点击出错位置查看强大的错误异常消息。但是,如果你已经有足够的测试基础(比如你为所有的测试写有自己的runner或者基类),我将会推荐你使用validateMockitoUsage(),因为对@After添加一个特别的功能时将是零成本。

具体例子可以参考Javadoc中的Mockito

verify(T mock)函数

public static <T> T verify(T mock)

验证发生的某些行为
等同于verify(mock, times(1)) 例如:

上面的写法等同于:

参数比较是通过equals()方法。可参考ArgumentCaptor或者ArgumentMatcher中关于匹配以及断言参数的方法。

尽管我们可以去验证对测试桩的调用,但通常它都是多余的。比如说你对foo.bar()打测试桩。如果你比较关心的是当某些情况foo.bar()中断了(经常在verify()方法执行之前),此时会返回什么。如果你的代码不关心是get(0)会返回什么那么它就不应该被添加测试桩。如果你还不确定?看这里

具体例子可以参考Javadoc中的Mockito

Parameters:

  • mock – 要被验证的
    Returns:

  • mock本身

verifyNoMoreInteractions(Object… mocks)函数

public static void verifyNoMoreInteractions(Object... mocks)

检查入参的mocks是否有任何未经验证的交互,你可以在验证你的mocks之后使用这个方法,用以确保你的mocks没有其它地方会被调用.

测试柱的调用也被看成是交互。

警告:一些使用者,倾向于经常使用verifyNoMoreInteractions()方法做大量经典的、期望-运行-验证的模拟,甚至是在所有的测试方法中使用。verifyNoMoreInteractions()并不被推荐于使用在所有的测试方法中。在交互测试工具中,verifyNoMoreInteractions()是一个很方便的断言。你只能在当它是明确的、相关的时候使用它。滥用它将导致多余的指定、不可维护的测试。你可以在这里查找更多的文章。

这个方法会在测试方法运行之前检查未经验证的调用,例如:在setUp(),@Before方法或者构造函数中。考虑到要写出良好优秀的代码,交互只能够在测试方法中。

示例:

verifyZeroInteractions(mockOne, mockTwo);

当你打空方法的测试桩,相关异常可参见:doThrow(Throwable),Stubbing可以被重写:比如:普通的测试桩可以使用固定的设置,但是测试方法能够重写它。切记重写测试桩是一种非常不推荐的写法,因为这样做会导致非常多的测试桩。

一旦这个方法打过桩,无论这个方法被调用多少次,这个方法会一直返回这个测试桩的值。

当你对相同的方法调用相同的参数打测试桩很多次,最后面的测试桩则非常重要

尽管我们可以去验证对测试桩的调用,但通常它都是多余的。比如说你对foo.bar()打测试桩。如果你比较关心的是当某些情况foo.bar()中断了(经常在verify()方法执行之前),此时会返回什么。如果你的代码不关心是get(0)会返回什么那么它就不应该被添加测试桩。如果你还不确定?看这里

具体例子可以参考Javadoc中的Mockito

Parameters:

  • methodCall – 调用的方法

Returns:

  • 通常是OngoingStubbing对象。不要为被返回的对象创建一个引用。

withSettings()函数

public static MockSettings withSettings()

可以在创建mock时添加设置。
不要经常去设置它。应该在使用简单的mocks时写简单的设置。跟着我重复:简单的测试会使整体的代码更简单,更可读、更可维护。如果你不能把测试写的很简单-那么请在测试时重构你的代码。

mock设置的例子

有两种原因推荐使用MockSettings.第一种,有需求要增加另外一种mock设置,这样用起来更方便。第二种,能够结合不同的moke设置以减少大量重载moke()方法。

具体可参考MockSettings文档来学习mock settins

Returns:

  • mock settings默认实例