n-w开头的函数 - 图1

n-w开头的函数

never()函数

public static VerificationMode never()

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

  1. verify(mock, never()).someMethod();

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

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

Returns:

  • 验证模式

only()函数

public static VerificationMode only()

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

  2.    verify(mock, only()).someMethod();
  3.    //上面这行代码是下面这两行代码的简写
  5.    verify(mock).someMethod();
  6.    verifyNoMoreInvocations(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()方法是代码中的害群之马（这意味着你的这个测试方法太多）

  1.    List mock = mock(List.class);
  2.    when(mock.size()).thenReturn(10);
  3.    mock.add(1);
  5.    reset(mock);
  6.    //此时会清除你之前所有的交互以及测试桩

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()。

例如：

  2.    SomeAbstract spy = spy(SomeAbstract.class);
  4.    //Robust API, via settings builder:
  5.    //稳定的API，充过builder方式来设置
  7.    OtherAbstract spy = mock(OtherAbstract.class, withSettings()
  8.       .useConstructor().defaultAnswer(CALLS_REAL_METHODS));
  10.    //Mocking a non-static inner abstract class:
  11.    //模拟一个非静态抽象内部类
  13.    InnerAbstract spy = mock(InnerAbstract.class, withSettings()
  14.       .useConstructor().outerInstance(outerInstance).defaultAnswer(CALLS_REAL_METHODS));

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)

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

  2.  stub(mock.someMethod()).toReturn(10);
  4.  //you can use flexible argument matchers, e.g:
  5.  //你可以使用灵活的参数匹配，例如：
  7.  stub(mock.someMethod(anyString())).toReturn(10);
  9.  //setting exception to be thrown:
  10.  //设置抛出的异常
  12.  stub(mock.someMethod("some arg")).toThrow(new RuntimeException());
  14.  //you can stub with different behavior for consecutive method calls.
  15.  // 你可以对不同作用的连续回调的方法打测试桩：
  16.  //Last stubbing (e.g: toReturn("foo")) determines the behavior for further consecutive calls.
  17.  // 最后面的测试桩（例如：返回一个对象："foo"）决定了接下来的回调方法以及它的行为。
  19.  stub(mock.someMethod("some arg"))
  20.   .toThrow(new RuntimeException())
  21.   .toReturn("foo");

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

  1.    //Instead of:
  2.    //替代为：
  3.    stub(mock.count()).toReturn(10);
  5.     //你可以这样做：
  6.    //You can do:
  7.    when(mock.count()).thenReturn(10);

当对一个返回值为空且抛出异常的方法打测试桩：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)方法代替去打空测试桩

  1.     //Instead of:
  2.     //替代为：
  3.    stubVoid(mock).toThrow(e).on().someVoidMethod();
  5.    //Please do:
  6.    //请这样做：
  7.    doThrow(e).when(mock).someVoidMethod();

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

  2.  stubVoid(mock).toThrow(new RuntimeException()).on().someMethod();
  4.  //you can stub with different behavior for consecutive calls.
  5.  //你可以对不同作用的连续回调的方法打测试桩：
  6.  //Last stubbing (e.g. toReturn()) determines the behavior for further consecutive calls.
  7.  //最后面的测试桩（例如：`toReturn()`）决定了接下来的回调方法以及它的行为。
  9.  stubVoid(mock)
  10.    .toThrow(new RuntimeException())
  11.    .toReturn()
  12.    .on().someMethod();

具体例子可以参考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)失败，然后它也一同失败。

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

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

  2.    //passes when someMethod() is called within given time span
  3.    //当`someMethod()`被以时间段的形式调用时通过
  5.    verify(mock, timeout(100)).someMethod();
  6.    //above is an alias to:
  7.    // 上面的是一个别名
  9.    verify(mock, timeout(100).times(1)).someMethod();
  11.    //passes as soon as someMethod() has been called 2 times before the given timeout
  12.    // 在超时之前，`someMethod()`通过了2次调用
  13.    verify(mock, timeout(100).times(2)).someMethod();
  15.    //equivalent: this also passes as soon as someMethod() has been called 2 times before the given timeout
  16.    //这个和上面的写法是等价的，也是在超时之前，`someMethod()`通过了2次调用
  17.    verify(mock, timeout(100).atLeast(2)).someMethod();
  19.    //verifies someMethod() within given time span using given verification mode
  20.    //在一个超时时间段内，用自定义的验证模式去验证`someMethod()`方法
  21.    //useful only if you have your own custom verification modes.
  22.    //只有在你有自己定制的验证模式时才有用
  24.    verify(mock, new Timeout(100, yourOwnVerificationMode)).someMethod();

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

Parameters:

  • millis - - 时间长度（单位：毫秒）

Returns:

  • 验证模式

time(int wantedNumberOfInvocations)函数

public static VerificationMode times(int wantedNumberOfInvocations)

允许验证调用方法的精确次数，例如：

  1. verify(mock, times(2)).someMethod("some arg");
  2. //连续调用该方法两次

具体例子可以参考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`会使这个用法一直有效，不过有一个问题请继续读下去。

错误示例:

  1.  //Oops, thenReturn() part is missing:
  2.  //当心，`thenReturn()`部分是缺失的
  4.  when(mock.get());
  6.  //Oops, verified method call is inside verify() where it should be on the outside:
  7.  //当心，下面验证方法的调用在`verify()`里面，其实应该在外面
  9.  verify(mock.execute());
  11.  //Oops, missing method to verify:
  12.  //当心，验证缺失方法
  14.  verify(mock);

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

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

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

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

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

verify(T mock)函数

public static <T> T verify(T mock)

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

  1.    verify(mock).someMethod("some arg");

上面的写法等同于：

  1.    verify(mock, times(1)).someMethod("some arg");

参数比较是通过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方法或者构造函数中。考虑到要写出良好优秀的代码，交互只能够在测试方法中。

示例：

  1.  //interactions
  2.  //交互
  3.  mock.doSomething();
  4.  mock.doSomethingUnexpected();
  6.  //verification
  7.  //验证
  8.  verify(mock).doSomething();
  10.  //following will fail because 'doSomethingUnexpected()' is unexpected
  11.  //因为'doSomethingUnexpected()'是未被期望的，所以下面将会失败
  12.  verifyNoMoreInteractions(mock);

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

Parameters:

  • mocks - 被验证的

verifyZeroInteractions(Object… mocks)函数

public static void verifyZeroInteractions(Object... mocks)

传进来的mocks之间没有任何交互。

  1.    verifyZeroInteractions(mockOne, mockTwo);

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

你也可以参考never()方法 - 这个方法很明确的表达了当前方法的用途. 具体例子可以参考Javadoc中的Mockito类

Parameters:

  • mocks - 被验证的

when(T methodCall)函数

public static <T> OngoingStubbing<T> when(T methodCall)

使测试桩方法生效。当你想让这个mock能调用特定的方法返回特定的值，那么你就可以使用它。 简而言之：当你调用x方法时会返回y。

when()是继承自已经废弃的方法stub(Object)

例如：

  1.  when(mock.someMethod()).thenReturn(10);
  3.  //you can use flexible argument matchers, e.g:
  4.  //你可以使用灵活的参数匹配，例如 
  5.  when(mock.someMethod(anyString())).thenReturn(10);
  7.  //setting exception to be thrown:
  8.  //设置抛出的异常
  9.  when(mock.someMethod("some arg")).thenThrow(new RuntimeException());
  11.  //you can set different behavior for consecutive method calls.
  12.  //你可以对不同作用的连续回调的方法打测试桩：
  13.  //Last stubbing (e.g: thenReturn("foo")) determines the behavior of further consecutive calls.
  14.  //最后面的测试桩（例如：返回一个对象："foo"）决定了接下来的回调方法以及它的行为。
  16.  when(mock.someMethod("some arg"))
  17.   .thenThrow(new RuntimeException())
  18.   .thenReturn("foo");
  20.  //Alternative, shorter version for consecutive stubbing:
  21.  //可以用以下方式替代，比较小版本的连贯测试桩：
  22.  when(mock.someMethod("some arg"))
  23.   .thenReturn("one", "two");
  24.  //is the same as:
  25.  //和下面的方式效果是一样的
  26.  when(mock.someMethod("some arg"))
  27.   .thenReturn("one")
  28.   .thenReturn("two");
  30.  //shorter version for consecutive method calls throwing exceptions:
  31.  //比较小版本的连贯测试桩并且抛出异常：
  32.  when(mock.someMethod("some arg"))
  33.   .thenThrow(new RuntimeException(), new NullPointerException();

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

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

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

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

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

Parameters:

  • methodCall - 调用的方法

Returns:

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

withSettings()函数

public static MockSettings withSettings()

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

mock设置的例子

  1.    //Creates mock with different default answer & name
  2.    //用不同的默认结果和名字去创建`mock`
  4.    Foo mock = mock(Foo.class, withSettings()
  5.        .defaultAnswer(RETURNS_SMART_NULLS)
  6.        .name("cool mockie"));
  8.    //Creates mock with different default answer, descriptive name and extra interfaces
  9.    ////用不同的默认结果和描述的名称以及额外的接口去创建`mock`
  10.    Foo mock = mock(Foo.class, withSettings()
  11.        .defaultAnswer(RETURNS_SMART_NULLS)
  12.        .name("cool mockie")
  13.        .extraInterfaces(Bar.class));

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

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

Returns:

  • mock settings默认实例