Mockito圖書館

時間  2019-11-26
標籤 mockito 圖書館 简体版
原文   原文鏈接
轉載：https://static.javadoc.io/org.mockito/mockito-core/2.12.0/org/mockito/Mockito.html#42
org.mockito

類Mockito

  • 直接已知子類：
    BDDMockito 

    公共類Mockito 擴展了ArgumentMatchers

    Mockito的標誌

    Mockito圖書館能夠模擬建立，驗證和存根。

    這個javadoc內容也能夠在http://mockito.org的網頁上找到。全部的文檔都保存在javadoc中，由於它保證了網頁內容與源代碼內容的一致性。即便脫機工做，它也容許直接從IDE訪問文檔。它激勵Mockito開發人員隨時隨地記錄他們編寫的代碼，天天都提交。html

    內容

    0.遷移到Mockito 2 
    0.1 Mockito Android支持
    0.2免配置內聯模擬
    1.讓咱們來驗證一些行爲！
    來自「簡明英漢詞典」有些殘肢呢 
    3.參數匹配器
    4.驗證確切的調用次數/至少一次/從不
    5.使用異常來替代void方法
    6.按順序驗證
    7.確保模擬中從未發生過交互
    8.查找多餘的調用
    9.速記mocks建立 - @Mock註釋
    10.連續調用連續調用（迭代器式stubbing）
    11.帶回調的stubbing 
    12. doReturn()| doThrow()| doAnswer()| doNothing()| doCallRealMethod()方法家族
    13. 
    監視真實對象14.更改未打開的調用的默認返回值（從1.7開始）
    15.捕獲進一步斷言的參數（從1.8.0開始）
    16.實際部分模擬（從1.8.0開始）
    17.重置模擬（自1.8 0.0）
    18.故障處理及驗證框架使用（因爲1.8.0）
    19.別名爲行爲驅動開發（因爲1.8.0）
    20串行化嘲笑（因爲1.8.1）
    21.新的註釋：@Captor，@Spy，@InjectMocks（因爲1.8。 3）
    22.驗證與超時（因爲1.8.5）
    23的自動實例化@Spies，@InjectMocks並構造注射善（因爲1.9.0）
    24.一襯墊存根（因爲1.9.0）
    25.驗證忽略存根（從1.9.0開始）
    26.嘲弄細節（在2.2.x中獲得改進）
    27.委託實際實例的調用（從1.9.5開始）
    28. MockMakerAPI（從1.9.5開始）
    29. BDD風格驗證自1.10.0）
    30.間諜或嘲笑抽象類（從2011年10月1日，在2.7.13和2.7.14進一步加強）
    31. Mockito嘲笑能夠在類加載器（從1.10.0）開始序列化 / 反序列化
    32.更好的通用（從1.10.0開始）
    33. Mockito JUnit規則（從1.10.17開始）
    34. 打開或關閉插件（從1.10.15開始）
    35.自定義驗證失敗消息（從2.1.0開始）
    36. Java 8 Lambda Matcher支持（自2.1.0起）
    37. Java 8自定義答案支持（自2.1.0起）
    38.元數據和通用類型保留（自2.1.0起）
    39.嘲笑最終類型，枚舉和最終方法（從2.1.0開始）
    40.（* new *）提升生產力和清理測試，使用更嚴格的Mockito（自2. +開始）
    41.（** new **）用於框架集成的高級公共API（自2.10。+起）
    42.（** new **）用於集成的新API：收聽驗證開始事件（自2.11。+起）

    0. 遷移到Mockito 2

    爲了繼續改進Mockito，進一步提升單元測試的體驗，咱們但願你升級到2.1.0！Mockito遵循 語義版本控制 ，僅在主要版本升級時才包含重大更改。在圖書館的生命週期中，突破變化是推出一系列改變現有行爲甚至更改API的全新功能所必需的。有關新版本的綜合指南，包括不兼容的更改，請參閱「  Mockito 2的新功能  」wiki頁面。咱們但願你喜歡Mockito 2！

    0.1。Mockito Android支持

    隨着Mockito版本2.6.1咱們運送「原生」Android支持。要啓用Android支持，請將`mockito-android`庫做爲依賴項添加到您的項目中。這個工件被髮布到同一個Mockito組織，能夠導入爲Android以下： 
    repositories {
   jcenter()
 }
 dependencies {
   testCompile "org.mockito:mockito-core:+" androidTestCompile "org.mockito:mockito-android:+" }
    您能夠繼續在常規虛擬機上運行相同的單元測試，在上面顯示的「testCompile」範圍內使用「mockito-core」工件。請注意，因爲Android VM的限制，您沒法使用Android上的 內聯模擬器 。若是您在Android上遇到模擬問題，請 在官方問題跟蹤器上 打開一個問題 。請提供您正在使用的Android版本和項目的相關性。

    0.2。免配置內聯模擬

    從版本2.7.6開始，咱們提供了「mockito-inline」工件，能夠 在 不配置MockMaker擴展文件的狀況下進行內聯模擬。要使用這個，添加`mockito-inline`而不是`mockito-core`神器，以下所示： 
    repositories {
   jcenter()
 }
 dependencies {
   testCompile "org.mockito:mockito-inline:+" }
    請注意，當內聯模擬功能被集成到默認模擬器中時，這個工件可能會被廢除。

    有關內聯模擬的更多信息，請參閱第39節。java

    1. 讓咱們驗證一些行爲！

    下面的例子嘲笑一個List，由於大多數人都熟悉的界面（如  add() ， get() ， clear() 方法）。
    實際上，請不要模擬List類。改用真實的實例。 
    //Let's import Mockito statically so that the code looks clearer import static org.mockito.Mockito.*; //mock creation List mockedList = mock(List.class); //using mock object mockedList.add("one"); mockedList.clear(); //verification verify(mockedList).add("one"); verify(mockedList).clear();

    一旦建立，模擬將記住全部的交互。而後，您能夠選擇性地驗證您感興趣的任何互動。android

    來自「簡明英漢詞典」有些殘肢呢

    //You can mock concrete classes, not just interfaces LinkedList mockedList = mock(LinkedList.class); //stubbing when(mockedList.get(0)).thenReturn("first"); when(mockedList.get(1)).thenThrow(new RuntimeException()); //following prints "first" System.out.println(mockedList.get(0)); //following throws runtime exception System.out.println(mockedList.get(1)); //following prints "null" because get(999) was not stubbed System.out.println(mockedList.get(999)); //Although it is possible to verify a stubbed invocation, usually it's just redundant //If your code cares what get(0) returns, then something else breaks (often even before verify() gets executed). //If your code doesn't care what get(0) returns, then it should not be stubbed. Not convinced? See here. verify(mockedList).get(0);
    • 默認狀況下，對於返回值的全部方法，mock將根據須要返回null，原始/原始包裝器值或空集合。例如，對於int / Integer爲0，對於布爾值/布爾值爲false。
    • 能夠覆蓋樁號：例如，普通樁能夠進入夾具設置，但測試方法能夠覆蓋它。請注意，覆蓋殘片是一種潛在的代碼異味，指出了太多的殘片
    • 一旦存留，該方法老是會返回一個存根值，而無論它被調用多少次。
    • 最後的茬更重要 - 當你屢次用相同的參數扼殺相同的方法。換句話說：存根的順序很重要，但它只是不多有意義的，例如當存根徹底相同的方法調用時，或者有時在使用參數匹配器時等等。

    3. 參數匹配器

    Mockito以天然的java風格驗證參數值：使用 equals() 方法。有時，當須要額外的靈活性時，你可使用參數匹配器： 
    //stubbing using built-in anyInt() argument matcher when(mockedList.get(anyInt())).thenReturn("element"); //stubbing using custom matcher (let's say isValid() returns your own matcher implementation): when(mockedList.contains(argThat(isValid()))).thenReturn("element"); //following prints "element" System.out.println(mockedList.get(999)); //you can also verify using an argument matcher verify(mockedList).get(anyInt()); //argument matchers can also be written as Java 8 Lambdas verify(mockedList).add(argThat(someString -> someString.length() > 5));

    參數匹配容許靈活的驗證或存根。 查看更多內置匹配器和自定義參數匹配器/ hamcrest匹配器的示例。 Click here or heregit

    有關自定義參數匹配器的信息，請查看javadoc的ArgumentMatcher類。github

    使用複雜的參數匹配是合理的。equals()與偶爾anyX()匹配使用的天然匹配風格傾向於給乾淨和簡單的測試。有時候重構代碼以容許equals()匹配甚至實現equals()方法來幫助進行測試會更好。正則表達式

    另外，閱讀第15節或javadoc的ArgumentCaptor類。 ArgumentCaptor是參數匹配器的一個特殊的實現，捕獲進一步的斷言的參數值。spring

    參數匹配器警告：編程

    若是使用參數匹配器，全部參數都必須由匹配器提供。json

    如下示例顯示驗證，但一樣適用於存根：api

    verify(mock).someMethod(anyInt(), anyString(), eq("third argument"));
   //above is correct - eq() is also an argument matcher verify(mock).someMethod(anyInt(), anyString(), "third argument"); //above is incorrect - exception will be thrown because third argument is given without an argument matcher.

    匹配方法anyObject()，eq() 不要返回匹配器。在內部，他們在堆棧上記錄匹配器並返回一個虛擬值（一般爲空）。這個實現是因爲Java編譯器強加的靜態類型的安全性。其後果是，你不能使用anyObject()，eq()驗證/存根方法以外的方法。

    4. 驗證調用的確切數量 / 至少x /從不

    //using mock mockedList.add("once"); mockedList.add("twice"); mockedList.add("twice"); mockedList.add("three times"); mockedList.add("three times"); mockedList.add("three times"); //following two verifications work exactly the same - times(1) is used by default verify(mockedList).add("once"); verify(mockedList, times(1)).add("once"); //exact number of invocations verification verify(mockedList, times(2)).add("twice"); verify(mockedList, times(3)).add("three times"); //verification using never(). never() is an alias to times(0) verify(mockedList, never()).add("never happened"); //verification using atLeast()/atMost() verify(mockedList, atLeastOnce()).add("three times"); verify(mockedList, atLeast(2)).add("three times"); verify(mockedList, atMost(5)).add("three times");

    次（1）是默認值。所以明確地使用時間（1）能夠省略。

    5. 使用異常來刪除void方法

    doThrow(new RuntimeException()).when(mockedList).clear(); //following throws RuntimeException: mockedList.clear();
    閱讀更多關於 doThrow() |  doAnswer() 家庭在方法 第12 。

     

    6. 依次驗證

    // A. Single mock whose methods must be invoked in a particular order List singleMock = mock(List.class); //using a single mock singleMock.add("was added first"); singleMock.add("was added second"); //create an inOrder verifier for a single mock InOrder inOrder = inOrder(singleMock); //following will make sure that add is first called with "was added first, then with "was added second" inOrder.verify(singleMock).add("was added first"); inOrder.verify(singleMock).add("was added second"); // B. Multiple mocks that must be used in a particular order List firstMock = mock(List.class); List secondMock = mock(List.class); //using mocks firstMock.add("was called first"); secondMock.add("was called second"); //create inOrder object passing any mocks that need to be verified in order InOrder inOrder = inOrder(firstMock, secondMock); //following will make sure that firstMock was called before secondMock inOrder.verify(firstMock).add("was called first"); inOrder.verify(secondMock).add("was called second"); // Oh, and A + B can be mixed together at will
    按順序進行驗證是很是靈活的 -  您沒必要 逐個驗證全部交互，只須要驗證您有興趣測試的全部交互。

    另外，您能夠建立一個InOrder對象，僅傳遞與按序驗證相關的模擬。

    7. 確保模擬中從未發生過交互

    //using mocks - only mockOne is interacted mockOne.add("one"); //ordinary verification verify(mockOne).add("one"); //verify that method was never called on a mock verify(mockOne, never()).add("two"); //verify that other mocks were not interacted verifyZeroInteractions(mockTwo, mockThree);

    8. 找到多餘的調用

    //using mocks mockedList.add("one"); mockedList.add("two"); verify(mockedList).add("one"); //following verification will fail verifyNoMoreInteractions(mockedList);
    一句 警告 ：誰作了不少經典的一些用戶，指望-運行-驗證嘲諷傾向於使用 verifyNoMoreInteractions() 很是頻繁，甚至在每一個測試方法。  verifyNoMoreInteractions() 不建議在每一個測試方法中使用。 verifyNoMoreInteractions() 是交互測試工具包的一個方便的斷言。只有在相關時才使用它。濫用它會致使 過分指定 ， 不易維護的 測試。你能夠 在這裏 找到更多的閱讀 。

    另請參閱never()- 它更加明確，並充分傳達意圖。

     

    9. 速記嘲笑創做- @Mock註釋

    • 最小化重複的模擬建立代碼。
    • 使測試類更具可讀性。
    • 使驗證錯誤易於閱讀，由於字段名稱 用於識別模擬。
    public class ArticleManagerTest { @Mock private ArticleCalculator calculator; @Mock private ArticleDatabase database; @Mock private UserProvider userProvider; private ArticleManager manager;
    重要！ 這須要在基類或測試運行的某個地方： 
    MockitoAnnotations.initMocks(testClass);
    你可使用內置的runner： MockitoJUnitRunner 或者一個規則： MockitoRule 。

    在這裏閱讀更多： MockitoAnnotations

    10. 連續調用（迭代器式存根）

    有時咱們須要爲同一個方法調用存根不一樣的返回值/異常。典型的用例多是嘲諷迭代器。原始版本的Mockito沒有這個功能來促進簡單的嘲笑。例如，而不是迭代器可使用 Iterable 或只是集合。那些提供天然的方式（例如使用真正的收藏）。在極少數的狀況下，連續調用多是有用的，可是：

     

    when(mock.someMethod("some arg")) .thenThrow(new RuntimeException()) .thenReturn("foo"); //First call: throws runtime exception: mock.someMethod("some arg"); //Second call: prints "foo" System.out.println(mock.someMethod("some arg")); //Any consecutive call: prints "foo" as well (last stubbing wins). System.out.println(mock.someMethod("some arg"));
    可選的，連續存根的較短版本： 
    when(mock.someMethod("some arg")) .thenReturn("one", "two", "three");
    警告 ：若是不使用連接 .thenReturn() 調用，而是使用具備相同匹配器或參數的多個存根，則每一個存根將覆蓋前一個存根： 
    //All mock.someMethod("some arg") calls will return "two" when(mock.someMethod("some arg")) .thenReturn("one") when(mock.someMethod("some arg")) .thenReturn("two")

    11. 與回調扼殺

    容許使用通用 Answer 接口存根。

    還有另外一個有爭議的特色，最初沒有包含在Mockito中。咱們建議您簡單地使用stubbing，thenReturn()或者 thenThrow()應該足以測試/測試任何干淨簡單的代碼。可是，若是您確實須要使用通用的Answer接口進行存根，請使用下面的示例：

    when(mock.someMethod(anyString())).thenAnswer(new Answer() { Object answer(InvocationOnMock invocation) { Object[] args = invocation.getArguments(); Object mock = invocation.getMock(); return "called with arguments: " + args; } }); //the following prints "called with arguments: foo" System.out.println(mock.someMethod("foo"));

    12. doReturn()| doThrow()| doAnswer()| doNothing()| doCallRealMethod()方法家族

    Stubbing void方法須要一個不一樣的方法， when(Object) 由於編譯器不喜歡方括號內的void方法。

    使用doThrow()時要與存根異常的無效方法：

    doThrow(new RuntimeException()).when(mockedList).clear(); //following throws RuntimeException: mockedList.clear();

     

    您可使用doThrow()，doAnswer()，doNothing()，doReturn() 和doCallRealMethod()在地方與調用相應的when()，對於任何方法。這是必要的，當你

    • 存根無效的方法
    • 間諜對象的存根方法（見下文）
    • 不止一次地存根相同的方法，在測試過程當中改變模擬的行爲。
    可是您可能更願意使用這些方法替代 when() 全部您的存根呼叫。

    閱讀更多關於這些方法：

    doReturn(Object)

    doThrow(Throwable...)

    doThrow(Class)

    doAnswer(Answer)

    doNothing()

    doCallRealMethod()

    13. 窺探真實的物體

    你能夠建立真實對象的間諜。當你使用間諜，那麼 真正的 方法被調用（除非方法被扼殺）。

    真正的間諜應該謹慎地偶爾使用，例如在處理遺留代碼時。

    對真實物體的窺視可能與「部分嘲諷」概念有關。 在釋放1.8以前，Mockito間諜不是真正的部分嘲諷。緣由是咱們認爲部分模擬是一種代碼味道。在某些時候，咱們發現了部分模擬的合法用例（第三方接口，對遺留代碼進行中間重構，整篇文章就 在這裏）

     

    List list = new LinkedList(); List spy = spy(list); //optionally, you can stub out some methods: when(spy.size()).thenReturn(100); //using the spy calls *real* methods spy.add("one"); spy.add("two"); //prints "one" - the first element of a list System.out.println(spy.get(0)); //size() method was stubbed - 100 is printed System.out.println(spy.size()); //optionally, you can verify verify(spy).add("one"); verify(spy).add("two");

    關於間諜真相的重要竅門！

    1. 有時使用when(Object)吝嗇的間諜是不可能或不切實際的。所以，當使用間諜時，請考慮doReturn| Answer| Throw()存根方法的家庭。例： 
      List list = new LinkedList(); List spy = spy(list); //Impossible: real method is called so spy.get(0) throws IndexOutOfBoundsException (the list is yet empty) when(spy.get(0)).thenReturn("foo"); //You have to use doReturn() for stubbing doReturn("foo").when(spy).get(0);
    2. Mockito *不會將調用委託給傳入的實例，而是實際建立一個副本。因此若是你保留真實的實例並與之交互，不要指望被偵察者知道這些交互以及它們對實際實例狀態的影響。其必然結果是，當* unstubbed *方法被調用*在間諜*，但*不上真正的實例*，你不會看到真正的實例的任何影響。
    3. 留意最後的方法。Mockito不會嘲笑最後的方法，因此底線是：當你窺探真實的物體時，你試圖存根最後的方法=麻煩。你也將沒法驗證這些方法。

    14.更改未發佈的調用的默認返回值（從1.7開始）

    您可使用指定的策略爲其返回值建立一個模擬。這是一個至關先進的功能，一般你不須要它來寫出體面的測試。可是，使用 遺留系統 可能會有幫助。

    這是默認的答案，因此只有當你不存在方法調用時纔會使用它。

    Foo mock = mock(Foo.class, Mockito.RETURNS_SMART_NULLS);
   Foo mockTwo = mock(Foo.class, new YourOwnAnswer());

    閱讀更多關於這個有趣的答案的答案：RETURNS_SMART_NULLS

    15. 捕捉參數用於進一步斷言（因爲1.8.0）

    Mockito以天然的java風格驗證參數值：使用 equals() 方法。這也是推薦的參數匹配方式，由於它使測試變得簡單明瞭。可是，在某些狀況下，在實際驗證以後對某些論點做出斷言是有幫助的。例如： 
    ArgumentCaptor<Person> argument = ArgumentCaptor.forClass(Person.class);
   verify(mock).doSomething(argument.capture());
   assertEquals("John", argument.getValue().getName());
    警告： 建議使用ArgumentCaptor進行驗證， 但不要 使用stubbing。使用帶有stub的ArgumentCaptor可能會下降測試可讀性，由於在assert（也就是驗證或'then'）塊以外建立了捕獲器。也能夠減小缺陷定位，由於若是不調用stubbed方法，則不會捕獲任何參數。

    ArgumentCaptor與自定義參數匹配器相關（請參閱ArgumentMatcher類javadoc ）。這兩種技術均可以用來肯定傳遞給mock的某些參數。不過，ArgumentCaptor可能更適合如下狀況：

    • 自定義參數匹配器不可能被重用
    • 你只須要它來斷言參數值來完成驗證
    自定義參數匹配器 ArgumentMatcher 一般更適合於存根。

    16. 真正的部分模擬（自1.8.0）

    最後，在郵件列表上進行了許多內部辯論和討論後，部分模擬支持被添加到Mockito。之前咱們把部分模擬視爲代碼味道。可是，咱們發現了部分模擬的合法用例 - 更多閱讀：  這裏

    在發佈以前，1.8版本 spy()並無產生真正的部分嘲諷，這讓一些用戶感到困惑。閱讀更多關於間諜：在這裏或在javadoc的spy(Object)方法。

     

    //you can create partial mock with spy() method: List list = spy(new LinkedList()); //you can enable partial mock capabilities selectively on mocks: Foo mock = mock(Foo.class); //Be sure the real implementation is 'safe'. //If real implementation throws exceptions or depends on specific state of the object then you're in trouble. when(mock.someMethod()).thenCallRealMethod();
    像往常同樣，您將閱讀 部分模擬警告 ：面向對象的編程經過將複雜性劃分爲單獨的，特定的SRPy對象來解決更復雜的問題。部分模擬如何適應這種模式？那麼，它只是不...部分模擬一般意味着複雜性已被移動到同一個對象上的不一樣方法。在大多數狀況下，這不是您想要設計應用程序的方式。

    可是，有些狀況下，部分模擬會變得很方便：處理不能輕易更改的代碼（第三方接口，傳統代碼的臨時重構等）。可是，我不會使用部分模擬來實現新的，測試驅動的，設計的代碼。

    17. 從新模擬（從1.8.0開始）

    智能Mockito用戶很難使用這個功能，由於他們知道這多是一個糟糕的測試的跡象。一般狀況下，你不須要重置你的模擬，只是爲每一個測試方法建立新的模擬。

    不要reset()考慮寫一些簡單，小而重點明確的測試方法，而不要考慮冗長的，過分規定的測試。 第一個潛在的代碼氣味正reset()處於測試方法的中間。這可能意味着你測試太多了。按照你的測試方法的低語：「請保持咱們的小而專一於單一的行爲」。在mockito郵件列表上有幾個線程。

    咱們添加reset()方法的惟一緣由是使用容器注入的模擬工做成爲可能。有關更多信息，請參閱FAQ（此處）。

    不要傷害你本身 reset()在測試方法的中間是一個代碼氣味（你可能測試太多）。

    List mock = mock(List.class);
   when(mock.size()).thenReturn(10); mock.add(1); reset(mock); //at this point the mock forgot any interactions & stubbing

    18. 故障排除和驗證框架使用（從1.8.0開始）

    首先，若是遇到任何問題，我建議您閱讀Mockito FAQ：https：  //github.com/mockito/mockito/wiki/FAQ

    若有疑問，您也能夠發送到mockito郵件列表：http： //groups.google.com/group/mockito

    接下來，您應該知道Mockito會驗證您是否始終正確使用它。可是，有一個問題，因此請閱讀javadocvalidateMockitoUsage()

    19. 行爲驅動開發的別名（自1.8.0開始）

    行爲驅動寫做測試的開發風格使用/ /  給/ / / /而後 評論做爲您的測試方法的基本部分。這正是咱們如何編寫測試的結果，咱們熱烈鼓勵您這樣作！

    在這裏開始瞭解BDD：http：//en.wikipedia.org/wiki/Behavior_Driven_Development

    問題是當前stubbing api與正則表達式的時候，若是沒有很好地集成//給定// // //而後評論。這是由於stubbing屬於測試的給定組件，而不屬於測試的when組件。所以，BDDMockito類引入了一個別名，以便您用BDDMockito.given(Object)方法存根方法調用。如今它與BDD風格測試的特定組件很是好地整合！

    如下是測試的樣子：

    import static org.mockito.BDDMockito.*; Seller seller = mock(Seller.class); Shop shop = new Shop(seller); public void shouldBuyBread() throws Exception { //given given(seller.askForBread()).willReturn(new Bread()); //when Goods goods = shop.buyBread(); //then assertThat(goods, containBread()); }

    20.可串行化的模擬（自1.8.1開始）

    嘲笑能夠被序列化。有了這個特性，你能夠在須要依賴的地方使用模擬器來進行序列化。

    警告：這應該不多用於單元測試。

    該行爲是針對具備不可靠外部依賴性的BDD規範的特定用例實現的。這是在Web環境中，來自外部依賴項的對象正在被序列化以在層之間傳遞。

    要建立可串行化的模擬使用MockSettings.serializable()：

    List serializableMock = mock(List.class, withSettings().serializable());

    模擬能夠被序列化，假設全部正常的 序列化要求都獲得了這個類的知足。

    由於間諜（...）方法沒有一個接受MockSettings的重載版本，因此製做一個真正的對象間諜序列化是一個更多的努力。不用擔憂，你幾乎不會使用它。

    List<Object> list = new ArrayList<Object>(); List<Object> spy = mock(ArrayList.class, withSettings() .spiedInstance(list) .defaultAnswer(CALLS_REAL_METHODS) .serializable());

    21.新的註釋：@Captor， @Spy， @InjectMocks（因爲1.8.3）

    版本1.8.3帶來新的註釋，有時可能會有所幫助：

    • @ Captor簡化了建立ArgumentCaptor - 當捕獲的參數是一個使人討厭的泛型類，而且您但願避免編譯器警告時，它很是有用
    • @ Spy- 你能夠用它來代替spy(Object)。
    • @ InjectMocks- 將模擬或間諜字段自動注入到測試對象中。

    請注意@ InjectMocks也能夠和@ Spy註解結合使用，這意味着Mockito會將mock注入到被測試的部分模擬中。這種複雜性是你僅僅使用部分模擬做爲最後手段的另外一個很好的理由。關於部分嘲諷，請參閱第16點。

    全部新的註釋*僅*處理MockitoAnnotations.initMocks(Object)。就像爲@ Mock註釋您可使用內置的亞軍：MockitoJUnitRunner或規則： MockitoRule。

     

    22. 超時驗證（自1.8.5開始）

    容許超時驗證。它會致使驗證等待指定的時間段進行指望的交互，而不是當即失敗，若是尚未發生。可能對併發條件下的測試有用。

    這個功能應該不多使用 - 找出測試你的多線程系統的更好方法。

    還沒有實施以使用InOrder驗證。

    例子：

     

    //passes when someMethod() is called within given time span verify(mock, timeout(100)).someMethod(); //above is an alias to: verify(mock, timeout(100).times(1)).someMethod(); //passes when someMethod() is called *exactly* 2 times within given time span verify(mock, timeout(100).times(2)).someMethod(); //passes when someMethod() is called *at least* 2 times within given time span verify(mock, timeout(100).atLeast(2)).someMethod(); //verifies someMethod() within given time span using given verification mode //useful only if you have your own custom verification modes. verify(mock, new Timeout(100, yourOwnVerificationMode)).someMethod();

    23. 自動實例化@Spies， @InjectMocks並構造注射善（因爲1.9.0）

    Mockito如今將嘗試實例化@ Spy並InjectMocks使用構造函數注入，setter注入或字段注入來實例化@ 字段。

    要利用此功能，您須要使用的優點MockitoAnnotations.initMocks(Object)，MockitoJUnitRunner 或MockitoRule。

    閱讀更多關於可用的技巧和javadoc中的注入規則 InjectMocks

    //instead: @Spy BeerDrinker drinker = new BeerDrinker(); //you can write: @Spy BeerDrinker drinker; //same applies to @InjectMocks annotation: @InjectMocks LocalPub;

    24. 單線存根（自1.9.0開始）

    Mockito如今可讓你建立嘲諷時。基本上，它容許在一行代碼中建立一個存根。這能夠有助於保持測試代碼的清潔。例如，一個無聊的存根能夠在測試中的字段初始化時建立和存根：

    public class CarTest { Car boringStubbedCar = when(mock(Car.class).shiftGear()).thenThrow(EngineNotStarted.class).getMock(); @Test public void should... {}

    25. 驗證忽略存根（從1.9.0開始）

    爲了驗證，Mockito如今容許忽略存根。有時加上verifyNoMoreInteractions()或驗證時有用inOrder()。有助於避免冗餘驗證，一般咱們對驗證存根不感興趣。

    警告，ignoreStubs()可能致使過分使用verifyNoMoreInteractions（ignoreStubs（...））; 請記住，Mockito不建議轟炸每一個測試與verifyNoMoreInteractions() javadoc概述的緣由verifyNoMoreInteractions(Object...)

    一些例子：

    verify(mock).foo();
 verify(mockTwo).bar();

 //ignores all stubbed methods: verifyNoMoreInteractions(ignoreStubs(mock, mockTwo)); //creates InOrder that will ignore stubbed InOrder inOrder = inOrder(ignoreStubs(mock, mockTwo)); inOrder.verify(mock).foo(); inOrder.verify(mockTwo).bar(); inOrder.verifyNoMoreInteractions();

    高級的例子和更多的細節能夠在javadoc中找到 ignoreStubs(Object...)

    26. 嘲弄細節（在2.2.x中改進）

    Mockito提供API來檢查模擬對象的細節。這個API對高級用戶和模擬框架集成商頗有用。

    //To identify whether a particular object is a mock or a spy: Mockito.mockingDetails(someObject).isMock(); Mockito.mockingDetails(someObject).isSpy(); //Getting details like type to mock or default answer: MockingDetails details = mockingDetails(mock); details.getMockCreationSettings().getTypeToMock(); details.getMockCreationSettings().getDefaultAnswer(); //Getting interactions and stubbings of the mock: MockingDetails details = mockingDetails(mock); details.getInteractions(); details.getStubbings(); //Printing all interactions (including stubbing, unused stubs) System.out.println(mockingDetails(mock).printInvocations());
    欲瞭解更多信息，請參閱javadoc  MockingDetails 。

    27. 委託實際實例（從1.9.5開始）

    對於使用一般的間諜API 很難嘲笑或間諜的對象的間諜或部分嘲笑是有用的。自從Mockito 1.10.11以後，表明可能會或可能不會與模擬類型相同。若是類型不一樣，則須要在委託類型上找到匹配的方法，不然拋出異常。這個功能的可能用例：

    • 最後的課程，但有一個接口
    • 已經自定義代理對象
    • 使用finalize方法的特殊對象，即避免執行2次

    與普通間諜的區別：

    • 常規spy（spy(Object)）包含spied實例的全部狀態，而且在spy上調用方法。偵察實例只用於模擬建立從狀態複製。若是你對一個普通間諜調用一個方法，而且在內部調用這個間諜的其餘方法，那麼這些調用就會被記住進行驗證，而且能夠被有效地刪除。
    • 委託的模擬只是將全部方法委託給委託。隨着方法的委託，委託一直在使用。若是你調用了一個模擬的方法，委託它在內部調用其餘方法，這些調用不會記住驗證，存根也不會影響他們。委託模擬不如常規間諜那麼強大，可是當不能建立常規間諜時，它是有用的。

    在文檔中查看更多信息AdditionalAnswers.delegatesTo(Object)。

    28. MockMakerAPI（自1.9.5以來）

    受谷歌Android傢伙的要求和補丁的驅動，Mockito如今提供了一個擴展點，容許替換代理生成引擎。默認狀況下，Mockito使用Byte Buddy 建立動態代理。

    擴展點是爲了擴展Mockito的高級用戶。例如，如今可使用針對的Mockito Android的測試與幫助dexmaker。

    欲瞭解更多細節，動機和例子請參閱文檔MockMaker。

    29. BDD風格驗證（從1.10.0開始）

    經過啓動驗證與BDD啓用行爲驅動開發（BDD）風格的驗證 ，而後 關鍵字。 
    given(dog.bark()).willReturn(2); // when ... then(person).should(times(2)).ride(bike);
    有關更多信息和示例，請參閱 BDDMockito.then(Object) }

    30. 偵察或嘲笑抽象類（自2011年10月1日起，在2.7.13和2.7.14中進一步增強）

    如今能夠方便地監視抽象類。請注意，過分使用間諜暗示代碼設計的氣味（見 spy(Object) ）。

    之前，間諜只能在對象的實例上進行。新的API能夠在建立模擬實例時使用構造函數。這對模擬抽象類特別有用，由於用戶再也不須要提供抽象類的實例。目前只支持無參數的構造函數，請告訴咱們是否不夠用。

    //convenience API, new overloaded spy() method: SomeAbstract spy = spy(SomeAbstract.class); //Mocking abstract methods, spying default methods of an interface (only available since 2.7.13) Function<foo, bar=""> function = spy(Function.class); //Robust API, via settings builder: OtherAbstract spy = mock(OtherAbstract.class, withSettings() .useConstructor().defaultAnswer(CALLS_REAL_METHODS)); //Mocking an abstract class with constructor arguments (only available since 2.7.14) SomeAbstract spy = mock(SomeAbstract.class, withSettings() .useConstructor("arg1", 123).defaultAnswer(CALLS_REAL_METHODS)); //Mocking a non-static inner abstract class: InnerAbstract spy = mock(InnerAbstract.class, withSettings() .useConstructor().outerInstance(outerInstance).defaultAnswer(CALLS_REAL_METHODS));
    欲瞭解更多信息，請參閱 MockSettings.useConstructor(Object...) 。

    31. Mockito嘲笑能夠經過類加載器序列化 / 反序列化（從1.10.0開始）

    Mockito在類加載器中引入序列化。與任何其餘形式的序列化同樣，模擬層次結構中的全部類型都必須可序列化，包含的答案。因爲這種序列化模式須要至關多的工做，這是一個選擇性的設置。 
    // use regular serialization mock(Book.class, withSettings().serializable()); // use serialization across classloaders mock(Book.class, withSettings().serializable(ACROSS_CLASSLOADERS));
    欲瞭解更多詳情，請參閱 MockSettings.serializable(SerializableMode) 。

    32. 更好的通用支持與深存根（自1.10.0）

    若是在課堂上能夠得到通常信息，則深度樁技術已獲得改進。這意味着相似這樣的類可使用而沒必要模擬行爲。 
    class Lines extends List<Line> { // ... } lines = mock(Lines.class, RETURNS_DEEP_STUBS); // Now Mockito understand this is not an Object but a Line Line line = lines.iterator().next();
    請注意，在大多數狀況下，模擬返回模擬是錯誤的。

    33. Mockito JUnit規則（從1.10.17開始）

    Mockito如今提供了一個JUnit規則。直到如今JUnit中有兩種方法來初始化經過註釋的Mockito如註釋字段，，，等。  @Mock @Spy @InjectMocks 如今你能夠選擇使用一個規則： 
    @RunWith(YetAnotherRunner.class) public class TheTest { @Rule public MockitoRule mockito = MockitoJUnit.rule(); // ... }
    更多信息請參閱 MockitoJUnit.rule() 。

    34. 交換機上或關閉的插件（15年10月1日以來）

    一個孵化功能使得mockito能夠切換mockito插件。更多信息在這裏 PluginSwitch 。

    35. 自定義驗證失敗消息（從2.1.0開始）

    若是驗證失敗，容許指定要打印的自定義消息。

    例子：

     

    // will print a custom message on verification failure verify(mock, description("This will print on failure")).someMethod(); // will work with any verification mode verify(mock, times(2).description("someMethod should be called twice")).someMethod();

    36. Java 8 Lambda Matcher支持（從2.1.0開始）

    您可使用Java 8 lambda表達式ArgumentMatcher來減小依賴關係ArgumentCaptor。若是您須要驗證模擬函數調用的輸入是否正確，那麼您一般會使用ArgumentCaptor找到使用的操做數，而後對其執行後續的斷言。雖然對於複雜的例子這多是有用的，它也是囉嗦。

    寫一個lambda來表示匹配是至關容易的。當你的函數的參數和argThat結合使用的時候，它會做爲一個強類型的對象傳遞給ArgumentMatcher，因此能夠對它作任何事情。

    例子：

     

    // verify a list only had strings of a certain length added to it // note - this will only compile under Java 8 verify(list, times(2)).add(argThat(string -> string.length() < 5)); // Java 7 equivalent - not as neat verify(list, times(2)).add(argThat(new ArgumentMatcher(){ public boolean matches(String arg) { return arg.length() < 5; } })); // more complex Java 8 example - where you can specify complex verification behaviour functionally verify(target, times(1)).receiveComplexObject(argThat(obj -> obj.getSubObject().get(0).equals("expected"))); // this can also be used when defining the behaviour of a mock under different inputs // in this case if the input list was fewer than 3 items the mock returns null when(mock.someMethod(argThat(list -> list.size()<3))).willReturn(null);

    37. Java 8自定義答案支持（從2.1.0開始）

    因爲Answer接口只有一個方法，因此已經能夠在很是簡單的狀況下使用lambda表達式在Java 8中實現它。您須要使用方法調用的參數的次數越多，您須要更多地對參數進行類型轉換InvocationOnMock。

    例子：

     

    // answer by returning 12 every time doAnswer(invocation -> 12).when(mock).doSomething(); // answer by using one of the parameters - converting into the right // type as your go - in this case, returning the length of the second string parameter // as the answer. This gets long-winded quickly, with casting of parameters. doAnswer(invocation -> ((String)invocation.getArgument(1)).length()) .when(mock).doSomething(anyString(), anyString(), anyString());
    爲了方便起見，能夠將使用方法調用參數的自定義答案/操做編寫爲Java 8 lambda表達式。即便在Java 7中，基於類型化界面的這些自定義答案也能夠減小樣板。特別是，這種方法將使測試使用回調函數更容易。方法 answer 和 answerVoid  可用於建立答案。他們依賴於相關的答案接口， org.mockito.stubbing 最多支持5個參數。

    例子：

     

    // Example interface to be mocked has a function like: void execute(String operand, Callback callback); // the example callback has a function and the class under test // will depend on the callback being invoked void receive(String item); // Java 8 - style 1 doAnswer(AdditionalAnswers.<string,callback>answerVoid((operand, callback) -> callback.receive("dummy")) .when(mock).execute(anyString(), any(Callback.class)); // Java 8 - style 2 - assuming static import of AdditionalAnswers doAnswer(answerVoid((String operand, Callback callback) -> callback.receive("dummy")) .when(mock).execute(anyString(), any(Callback.class)); // Java 8 - style 3 - where mocking function to is a static member of test class private static void dummyCallbackImpl(String operation, Callback callback) { callback.receive("dummy"); } doAnswer(answerVoid(TestClass::dummyCallbackImpl) .when(mock).execute(anyString(), any(Callback.class)); // Java 7 doAnswer(answerVoid(new VoidAnswer2<string, callback="">() { public void answer(String operation, Callback callback) { callback.receive("dummy"); }})).when(mock).execute(anyString(), any(Callback.class)); // returning a value is possible with the answer() function // and the non-void version of the functional interfaces // so if the mock interface had a method like boolean isSameString(String input1, String input2); // this could be mocked // Java 8 doAnswer(AdditionalAnswers.<boolean,string,string>answer((input1, input2) -> input1.equals(input2)))) .when(mock).execute(anyString(), anyString()); // Java 7 doAnswer(answer(new Answer2<string, string,="" string="">() { public String answer(String input1, String input2) { return input1 + input2; }})).when(mock).execute(anyString(), anyString());

    38. 元數據和通用類型保留（從2.1.0開始）

    Mockito如今保留對嘲笑的方法和類型以及通用元數據的註釋。之前，模擬類型不保留對類型的註釋，除非它們是顯式繼承的，而且永遠不會在方法上保留註釋。所以，如今下列條件成立：

    @MyAnnotation class Foo { List<String> bar() { ... } } Class<?> mockType = mock(Foo.class).getClass(); assert mockType.isAnnotationPresent(MyAnnotation.class); assert mockType.getDeclaredMethod("bar").getGenericReturnType() instanceof ParameterizedType; MyAnnotation class Foo { List<String> bar() { ... } } Class<?> mockType = mock(Foo.class).getClass(); assert mockType.isAnnotationPresent(MyAnnotation.class); assert mockType.getDeclaredMethod("bar").getGenericReturnType() instanceof ParameterizedType;

    當使用Java 8時，Mockito如今也保留了類型註釋。這是默認行爲，若是使用替代方法可能不會成立MockMaker。

    39. 嘲笑最終類型，枚舉和最終方法（從2.1.0開始）

    Mockito如今提供了一個模擬 Incubating 最終類和方法的可選支持。這是一個奇妙的改進，證實了Mockito對於改善測試體驗的永恆追求。咱們的抱負是Mockito「最後的課程和方法」。之前他們被認爲是 unmockable ，防止用戶嘲笑。咱們已經開始討論如何使這個功能默認啓用。目前，該功能仍然是可選的，由於咱們等待來自社區的更多反饋。

    此功能默認關閉，由於它基於徹底不一樣的嘲笑機制，須要來自社區的更多反饋。

    這個替代的模擬器使用Java Instrumentation API和子類的組合，而不是建立一個新的類來表示一個模擬。這樣，就能夠模擬最終的類型和方法。

    這個模擬器默認關閉，由於它是基於徹底不一樣的嘲弄機制，須要來自社區的更多反饋。它能夠經過mockito擴展機制顯式激活，只需在類路徑中建立一個/mockito-extensions/org.mockito.plugins.MockMaker 包含該值的文件便可mock-maker-inline。

    爲了方便起見，Mockito團隊在模擬器製造商預先配置的地方提供了一個神器。在您的項目中包含mockito-inline工件，而不是使用 mockito-core工件。請注意，一旦嘲笑最終的類和方法被整合到默認的模擬器中，這個工件可能會被終止。

    關於這個模擬器的一些值得注意的筆記：

    • 嘲笑最終的類型和枚舉是不符合模擬設置，如：
      • 明確的序列化支持 withSettings().serializable()
      • 額外的接口 withSettings().extraInterfaces()
    • 有些方法不能被嘲弄
      • 包的可見方法 java.*
      • native 方法
    • 這個模擬器是圍繞Java代理運行時附件設計的; 這須要一個兼容的JVM，它是JDK（或Java 9 VM）的一部分。當在Java 9以前的非JDK虛擬機上運行時，能夠 在啓動JVM時使用參數手動添加Byte Buddy Java代理程序jar-javaagent。

    若是你對這個功能的更多細節感興趣，請閱讀javadoc org.mockito.internal.creation.bytebuddy.InlineByteBuddyMockMaker

    40. （*新*）提升生產力和清潔測試與「更嚴格」Mockito（自2 + +）

    要快速瞭解「更嚴格」的Mockito如何使您的工做效率更高，並使測試更加清潔，請參閱： Mockito默認是一個「鬆散」的嘲諷框架。嘲笑能夠在沒有預先設定任何指望的狀況下進行互動。這是有意的，它經過強迫用戶明確他們想要存根/驗證的內容來提升測試的質量。它也很是直觀，易於使用，並與「給定」，「當時」，「那麼」乾淨的測試代碼模板很好地融合。這與過去的經典嘲諷框架不一樣，默認狀況下它們是「嚴格的」。

    默認狀況下，「鬆散」使得Mockito測試有時難以調試。在某些狀況下，錯誤配置的樁（如使用錯誤的參數）會強制用戶使用調試器運行測試。理想狀況下，測試失敗是顯而易見的，不須要調試器來肯定根本緣由。從版本2.1開始，Mockito已經得到了將框架推向「嚴格」的新功能。咱們但願Mockito可以提供出色的可調試性，同時不會失去其核心嘲笑風格，並針對直觀性，清晰度和清晰的測試代碼進行了優化。

    幫助Mockito！嘗試新功能，給咱們反饋，參加GitHub 第769期關於Mockito嚴格性的討論 。

    41. （** **新）先進的架構整合公共API（自2.10。+）

    在2017年夏季，咱們決定Mockito  應該  爲高級框架集成提供更好的API 。新的API不適用於想要編寫單元測試的用戶。它旨在用於其餘測試工具和模擬框架，須要擴展或包裝Mockito一些自定義的邏輯。在設計和實施過程（ 問題1110 ）期間，咱們已經開發並更改了如下公共API元素：
    • 新增功能MockitoPlugins- 使框架集成商能夠訪問默認的Mockito插件。當須要實現自定義插件（如MockMaker 將某些行爲委託給默認的Mockito實現）時很是有用。
    • 新建MockSettings.build(Class)- 建立Mockito稍後使用的模擬設置的不可變視圖。用於建立調用InvocationFactory或實現自定義時MockHandler。
    • 新建MockingDetails.getMockHandler()- 其餘框架可使用模擬處理程序以編程方式模擬模擬對象上的調用。
    • 新建MockHandler.getMockSettings()- 有用的獲取模擬對象建立的設置。
    • 新建InvocationFactory- 提供建立Invocation對象實例的方法。對於須要以編程方式模擬模擬對象的方法調用的框架集成很是有用。
    • 新建MockHandler.getInvocationContainer()- 提供對沒有方法的調用容器對象（標記接口）的訪問。容器須要隱藏內部實現，並避免泄漏到公共API。
    • 改變Stubbing- 它如今擴展Answer接口。它是向後兼容的，由於存根接口不可擴展（請參閱NotExtensible）。這個改變對咱們的用戶應該是無縫的。
    • 棄用InternalMockHandler- 爲了適應API的變化，咱們須要棄用這個接口。界面老是被記錄爲內部的，咱們沒有證據代表它被社區使用。棄用應該徹底無縫的爲咱們的用戶。
    • NotExtensible - 公共註釋，指示用戶不該該提供給定類型的自定義實現。幫助框架集成商和咱們的用戶瞭解如何安全地使用Mockito API。
    你有反饋嗎？請在 第1110期 發表評論。

    42. （** new **）用於集成的新API：收聽驗證開始事件（自2.11。+起）

    Spring Boot  等框架集成須要公共API來解決雙代理用例（ 問題1191 ）。咱們補充說：

    • 字段細節

      • RETURNS_DEFAULTS

        public static final  Answer < Object > RETURNS_DEFAULTS
        Answer 每一個模擬的默認值， 若是 模擬不被扼殺。一般它只是返回一些空的值。

        Answer 能夠用來定義未打開的調用的返回值。

        此實現首先嚐試全局配置，若是沒有全局配置，則將使用返回零，空集合，空值等的默認答案。

      • RETURNS_SMART_NULLS

        public static final  Answer： < Object > RETURNS_SMART_NULLS
        可選 Answer 用於 mock(Class, Answer) 。

        Answer 能夠用來定義未打開的調用的返回值。

        這個實如今處理遺留代碼時會頗有幫助。未被拼接的方法一般返回null。若是你的代碼使用了一個未經調用的調用返回的對象，你將獲得一個NullPointerException異常。Answer的這個實現返回SmartNull而不是null。 SmartNull比NPE提供更好的異常消息，由於它指出了未調用方法被調用的行。你只需點擊堆棧跟蹤。

        ReturnsSmartNulls首先嚐試返回普通的值（零，空集合，空字符串等），而後嘗試返回SmartNull。若是返回類型是final，則null返回plain 。

        ReturnsSmartNulls 將多是Mockito 3.0.0中的默認返回值策略

        例：

        Foo mock = mock(Foo.class, RETURNS_SMART_NULLS);

   //calling unstubbed method here: Stuff stuff = mock.getStuff(); //using object returned by unstubbed call: stuff.doSomething(); //Above doesn't yield NullPointerException this time! //Instead, SmartNullPointerException is thrown. //Exception's cause links to unstubbed mock.getStuff() - just click on the stack trace.

      • RETURNS_MOCKS

        public static final  Answer： < Object > RETURNS_MOCKS
        可選 Answer 用於 mock(Class, Answer)

        Answer 能夠用來定義未打開的調用的返回值。

        這個實如今處理遺留代碼時會頗有幫助。

        ReturnsMocks首先嚐試返回普通的值（零，空集合，空字符串等），而後嘗試返回模擬。若是返回類型不能被模擬（例如final），則null返回plain 。

         

      • RETURNS_DEEP_STUBS

        public static final  Answer： < Object > RETURNS_DEEP_STUBS
        可選 Answer 用於 mock(Class, Answer) 。

        顯示深度存根工做原理的示例：

        Foo mock = mock(Foo.class, RETURNS_DEEP_STUBS);

   // note that we're stubbing a chain of methods here: getBar().getName() when(mock.getBar().getName()).thenReturn("deep"); // note that we're chaining method calls: getBar().getName() assertEquals("deep", mock.getBar().getName());

         

        警告： 常規清潔代碼不多須要此功能！將其留做遺留代碼。嘲諷一個嘲諷返回一個模擬，返回一個模擬，（...），返回一些有意義的提示，違反得墨忒耳法或嘲弄價值對象（一個衆所周知的反模式）。

        我有一天在網上看到了很好的報價：每次模擬回來模擬一個仙女死亡。

        請注意，這個答案將返回與存根相匹配的現有模擬。這種行爲對於深存根是能夠的，而且容許驗證在鏈的最後模擬上工做。

        when(mock.getBar(anyString()).getThingy().getName()).thenReturn("deep"); mock.getBar("candy bar").getThingy().getName(); assertSame(mock.getBar(anyString()).getThingy().getName(), mock.getBar(anyString()).getThingy().getName()); verify(mock.getBar("candy bar").getThingy()).getName(); verify(mock.getBar(anyString()).getThingy()).getName();

         

        驗證只適用於鏈中的最後一個模擬。您可使用驗證模式。

        when(person.getAddress(anyString()).getStreet().getName()).thenReturn("deep"); when(person.getAddress(anyString()).getStreet(Locale.ITALIAN).getName()).thenReturn("deep"); when(person.getAddress(anyString()).getStreet(Locale.CHINESE).getName()).thenReturn("deep"); person.getAddress("the docks").getStreet().getName(); person.getAddress("the docks").getStreet().getLongName(); person.getAddress("the docks").getStreet(Locale.ITALIAN).getName(); person.getAddress("the docks").getStreet(Locale.CHINESE).getName(); // note that we are actually referring to the very last mock in the stubbing chain. InOrder inOrder = inOrder( person.getAddress("the docks").getStreet(), person.getAddress("the docks").getStreet(Locale.CHINESE), person.getAddress("the docks").getStreet(Locale.ITALIAN) ); inOrder.verify(person.getAddress("the docks").getStreet(), times(1)).getName(); inOrder.verify(person.getAddress("the docks").getStreet()).getLongName(); inOrder.verify(person.getAddress("the docks").getStreet(Locale.ITALIAN), atLeast(1)).getName(); inOrder.verify(person.getAddress("the docks").getStreet(Locale.CHINESE)).getName();

         

        多少深存根在內部工做？

        //this: Foo mock = mock(Foo.class, RETURNS_DEEP_STUBS); when(mock.getBar().getName(), "deep"); //is equivalent of Foo foo = mock(Foo.class); Bar bar = mock(Bar.class); when(foo.getBar()).thenReturn(bar); when(bar.getName()).thenReturn("deep");

         

        當包含在鏈中的任何返回類型的方法不能被模擬時（例如：是原始類仍是最終類），此功能將不起做用。這是由於java類型的系統。

      • CALLS_REAL_METHODS

        public static final  Answer < Object > CALLS_REAL_METHODS
        可選 Answer 用於 mock(Class, Answer)

        Answer 能夠用來定義未打開的調用的返回值。

        這個實如今處理遺留代碼時會頗有幫助。當使用這個實現時，未解壓的方法將委託給真正的實現。這是建立一個默認調用真實方法的部分模擬對象的一種方法。

        像往常同樣，您將閱讀部分模擬警告：面向對象的編程經過將複雜性劃分爲單獨的，特定的SRPy對象來解決更復雜的問題。部分模擬如何適應這種模式？那麼，它只是不...部分模擬一般意味着複雜性已被移動到同一個對象上的不一樣方法。在大多數狀況下，這不是您想要設計應用程序的方式。

        可是，有些狀況下，部分模擬會變得很方便：處理不能輕易更改的代碼（第三方接口，傳統代碼的臨時重構等）。可是，我不會使用部分模擬來實現新的，測試驅動的，設計的代碼。

        例：

        Foo mock = mock(Foo.class, CALLS_REAL_METHODS);

 // this calls the real implementation of Foo.getSomething() value = mock.getSomething(); when(mock.getSomething()).thenReturn(fakeValue); // now fakeValue is returned value = mock.getSomething();

      • RETURNS_SELF

        public static final  Answer < Object > RETURNS_SELF
        可選 Answer 用於 mock(Class, Answer) 。當一個方法被調用返回一個Type等於該類或一個超類的方法時，容許Builder mock返回自身。

        請記住，這個答案使用方法的返回類型。若是這個類型能夠分配給模擬類，它將返回模擬。所以，若是你有一個方法返回一個超類（例如Object）它將匹配並返回模擬。

        考慮HttpRequesterWithHeaders中使用的HttpBuilder。 
        public class HttpRequesterWithHeaders { private HttpBuilder builder; public HttpRequesterWithHeaders(HttpBuilder builder) { this.builder = builder; } public String request(String uri) { return builder.withUrl(uri) .withHeader("Content-type: application/json") .withHeader("Authorization: Bearer") .request(); } } private static class HttpBuilder { private String uri; private List<String> headers; public HttpBuilder() { this.headers = new ArrayList<String>(); } public HttpBuilder withUrl(String uri) { this.uri = uri; return this; } public HttpBuilder withHeader(String header) { this.headers.add(header); return this; } public String request() { return uri + headers.toString(); } }
        如下測試將成功 
        @Test public void use_full_builder_with_terminating_method() { HttpBuilder builder = mock(HttpBuilder.class, RETURNS_SELF); HttpRequesterWithHeaders requester = new HttpRequesterWithHeaders(builder); String response = "StatusCode: 200"; when(builder.request()).thenReturn(response); assertThat(requester.request("URI")).isEqualTo(response); }

    • 構造函數的細節

      • 的Mockito

        公衆Mockito（）

    • 方法細節

      • 嘲笑

        public static <T> T mock（Class <T> classToMock）
        建立給定的類或接口的模擬對象。

        見的例子中的javadoc Mockito類

        參數：
        classToMock  - 類或接口來模擬
        返回：
        模擬對象

      • 嘲笑

        public static <T> T mock（Class <T> classToMock，
                          String  name）
        指定模擬名稱。命名模擬可能對調試有幫助 - 名稱用於全部驗證錯誤。

        請注意，命名模擬不適用於使用太多模擬或協做者的複雜代碼。 若是你有太多的mock，那麼重構代碼，這樣很容易測試/調試，而沒必要命名模擬。

        若是你使用@Mock註釋，那麼你已經免費命名模擬！ @Mock使用字段名稱做爲模擬名稱。Read more.

        見的例子中的javadoc Mockito類

        參數：
        classToMock  - 類或接口來模擬
        name  - 模擬
        返回：
        模擬對象

      • mockingDetails

        公共靜態  MockingDetails  mockingDetails（Object  toInspect）
        返回一個MockingDetails實例，該實例能夠檢查特定對象的Mockito相關信息。能夠用來找出給定的對象是不是Mockito模擬，或者找出給定的模擬是間諜仍是模擬。

        在未來的Mockito版本中，MockingDetails可能會增加，並提供有關模擬的其餘有用信息，例如調用，存根信息等。

        參數：
        toInspect  - - 檢查對象。空輸入是容許的。
        返回：
        一個 MockingDetails 實例。
        以來：
        1.9.5

      • 嘲笑

        public static <T> T mock（Class <T> classToMock，
                          Answer  defaultAnswer）
        建立一個指定的策略模擬其交互的答案。這是一個至關先進的功能，一般你不須要它來寫出體面的測試。可是，使用舊系統時可能會有所幫助。

        這是默認的答案，因此只有當你不存在方法調用時纔會使用它。

        Foo mock = mock(Foo.class, RETURNS_SMART_NULLS);
   Foo mockTwo = mock(Foo.class, new YourOwnAnswer());

        見的例子中的javadoc Mockito類

        參數：
        classToMock  - 類或接口來模擬
        defaultAnswer  - 未打開的方法的默認答案
        返回：
        模擬對象

      • 嘲笑

        public static <T> T mock（Class <T> classToMock，
                          MockSettings  mockSettings）
        用一些非標準設置建立一個模擬。

        模擬的配置點數量增加，因此咱們須要一個流利的方式來引入新的配置，而不會增長更多的重載Mockito.mock（）方法。所以MockSettings。

        Listener mock = mock(Listener.class, withSettings()
     .name("firstListner").defaultBehavior(RETURNS_SMART_NULLS)); );
        當心使用，偶爾使用 。什麼多是你的測試須要非標準模擬的緣由？被測試的代碼是如此複雜以致於它須要非標準的模擬？你不喜歡重構測試中的代碼，因此它是可測試的一個簡單的方法？

        也能夠看看 withSettings()

        見的例子中的javadoc Mockito類

        參數：
        classToMock  - 類或接口來模擬
        mockSettings  - 額外的模擬設置
        返回：
        模擬對象

      • 間諜

        公共靜態<T> T間諜（T對象）
        建立真實對象的間諜。間諜調用 真正的 方法，除非他們被扼殺。

        真正的間諜應該謹慎地偶爾使用，例如在處理遺留代碼時。

        像往常同樣，您將閱讀部分模擬警告：面向對象編程經過將複雜性劃分爲單獨的，特定的SRPy對象來解決複雜性問題。部分模擬如何適應這種模式？那麼，它只是不...部分模擬一般意味着複雜性已被移動到同一個對象上的不一樣方法。在大多數狀況下，這不是您想要設計應用程序的方式。

        可是，有些狀況下，部分模擬會變得很方便：處理不能輕易更改的代碼（第三方接口，傳統代碼的臨時重構等）。可是，我不會使用部分模擬來實現新的，測試驅動的，設計的代碼。

        例：

        List list = new LinkedList(); List spy = spy(list); //optionally, you can stub out some methods: when(spy.size()).thenReturn(100); //using the spy calls real methods spy.add("one"); spy.add("two"); //prints "one" - the first element of a list System.out.println(spy.get(0)); //size() method was stubbed - 100 is printed System.out.println(spy.size()); //optionally, you can verify verify(spy).add("one"); verify(spy).add("two");

        關於間諜真相的重要竅門！

        1. 有時使用when(Object)吝嗇的間諜是不可能或不切實際的。所以，對於間諜，建議始終使用doReturn| Answer| Throw()| CallRealMethod 存根方法的家庭。例： 
          List list = new LinkedList(); List spy = spy(list); //Impossible: real method is called so spy.get(0) throws IndexOutOfBoundsException (the list is yet empty) when(spy.get(0)).thenReturn("foo"); //You have to use doReturn() for stubbing doReturn("foo").when(spy).get(0);
        2. Mockito *不會將調用委託給傳入的實例，而是實際建立一個副本。因此若是你保留真實的實例並與之交互，不要指望被偵察者知道這些交互以及它們對實際實例狀態的影響。其必然結果是，當* unstubbed *方法被調用*在間諜*，但*不上真正的實例*，你不會看到真正的實例的任何影響。
        3. 留意最後的方法。Mockito不會嘲笑最後的方法，因此底線是：當你窺探真實的物體時，你試圖存根最後的方法=麻煩。你也將沒法驗證這些方法。

        見的例子中的javadoc Mockito類

        請注意，間諜不會有任何關於間諜類型的註釋，由於CGLIB不會重寫它們。對於依靠間諜來得到這些註釋的代碼來講，可能會很麻煩。

        參數：
        object  - 監視
        返回：
        一個真正的對象的間諜

      • 間諜

        @Incubating 
public static <T> T spy（Class <T> classToSpy）
        請參閱文檔 spy(Object) 。濫用間諜暗示代碼設計的氣味。

        這個方法與原來的方法相反spy(Object)，是基於類而不是一個對象來建立一個間諜。有時候，基於類建立間諜更爲方便，並避免提供一個間諜對象的實例。這對偵察抽象類很是有用，由於它們不能被實例化。另見MockSettings.useConstructor(Object...)。

        例子：

        SomeAbstract spy = spy(SomeAbstract.class);

   //Robust API, via settings builder: OtherAbstract spy = mock(OtherAbstract.class, withSettings() .useConstructor().defaultAnswer(CALLS_REAL_METHODS)); //Mocking a non-static inner abstract class: InnerAbstract spy = mock(InnerAbstract.class, withSettings() .useConstructor().outerInstance(outerInstance).defaultAnswer(CALLS_REAL_METHODS));
        類型參數：
        T  - 間諜的類型
        參數：
        classToSpy  - 要窺探的班級
        返回：
        提供的類的間諜
        以來：
        1.10.12

      • 何時

        public static <T>  OngoingStubbing <T> when（T methodCall）
        啓用存根方法。當你想要模擬特定的方法被調用時返回特定的值使用它。

        簡單地說：「 當 x方法被調用，而後返回y」。

        例子：

        when(mock.someMethod()).thenReturn(10); //you can use flexible argument matchers, e.g: when(mock.someMethod(anyString())).thenReturn(10); //setting exception to be thrown: when(mock.someMethod("some arg")).thenThrow(new RuntimeException()); //you can set different behavior for consecutive method calls. //Last stubbing (e.g: thenReturn("foo")) determines the behavior of further consecutive calls. when(mock.someMethod("some arg")) .thenThrow(new RuntimeException()) .thenReturn("foo"); //Alternative, shorter version for consecutive stubbing: when(mock.someMethod("some arg")) .thenReturn("one", "two"); //is the same as: when(mock.someMethod("some arg")) .thenReturn("one") .thenReturn("two"); //shorter version for consecutive method calls throwing exceptions: when(mock.someMethod("some arg")) .thenThrow(new RuntimeException(), new NullPointerException();
        有關throwables的void方法，請參見：  doThrow(Throwable...)

        能夠覆蓋樁號：例如，普通樁能夠進入夾具設置，但測試方法能夠覆蓋它。請注意，覆蓋殘片是一種潛在的代碼異味，指出了太多的殘片。

        一旦被存根，該方法將老是返回存根值，而無論被調用的次數多少。

        最後的茬更重要 - 當你屢次用相同的參數扼殺相同的方法。

        儘管能夠驗證存根調用，但一般這只是多餘的。比方說，你已經殘廢了foo.bar()。若是你的代碼關心什麼foo.bar()返回，那麼別的東西就會中斷（一般在verify()執行以前）。若是你的代碼不在意什麼get(0)返回，那麼它不該該被扼殺。不服氣？看到這裏。

        見的例子中的javadoc Mockito類

        參數：
        methodCall  - 方法被扼殺
        返回：
        OngoingStubbing對象用於流利地存根。  不要 建立對此返回對象的引用。

      • 校驗

        public static <T> T verify（T mock）
        驗證 一次發生的 某些行爲。

        別名verify(mock, times(1))如：

        verify(mock).someMethod("some arg");
        以上至關於： 
        verify(mock, times(1)).someMethod("some arg");

        使用equals()方法比較傳遞的參數。閱讀ArgumentCaptor或ArgumentMatcher找出其餘方式匹配/斷言傳遞的參數。

        儘管能夠驗證存根調用，但一般這只是多餘的。比方說，你已經殘廢了foo.bar()。若是你的代碼關心什麼foo.bar()返回，那麼別的東西就會中斷（一般在verify()執行以前）。若是你的代碼不在意什麼get(0)返回，那麼它不該該被扼殺。不服氣？看到這裏。

        見的例子中的javadoc Mockito類

        參數：
        mock  - 待驗證
        返回：
        模擬對象自己

      • 校驗

        public static <T> T驗證（T模擬，
                            VerificationMode  模式）
        驗證某些行爲發生至少一次/確切的次數/從不。例如： 
        verify(mock, times(5)).someMethod("was called five times"); verify(mock, atLeast(2)).someMethod("was called at least two times"); //you can use flexible argument matchers, e.g: verify(mock, atLeastOnce()).someMethod(anyString());
        次（1）是默認值 ，能夠省略

        使用equals()方法比較傳遞的參數。閱讀ArgumentCaptor或ArgumentMatcher找出其餘方式匹配/斷言傳遞的參數。

         

        參數：
        mock  - 待驗證
        mode  - times（x），atLeastOnce（）或never（）
        返回：
        模擬對象自己

      • 重啓

        public static <T> void reset（T ... mocks）
        智能Mockito用戶很難使用這個功能，由於他們知道這多是一個糟糕的測試的跡象。一般狀況下，你不須要重置你的模擬，只是爲每一個測試方法建立新的模擬。

        不要#reset()考慮寫一些簡單，小而重點明確的測試方法，而不要考慮冗長的，過分規定的測試。 第一個潛在的代碼氣味正reset()處於測試方法的中間。這可能意味着你測試太多了。按照你的測試方法的低語：「請保持咱們的小而專一於單一的行爲」。在mockito郵件列表上有幾個線程。

        咱們添加reset()方法的惟一緣由是使用容器注入的模擬工做成爲可能。欲瞭解更多信息，請參閱常見問題（這裏）。

        不要傷害你本身 reset()在測試方法的中間是一個代碼氣味（你可能測試太多）。

        List mock = mock(List.class);
   when(mock.size()).thenReturn(10); mock.add(1); reset(mock); //at this point the mock forgot any interactions & stubbing
        類型參數：
        T  - 嘲笑的類型
        參數：
        mocks  - 重置

      • clearInvocations

        public static <T> void clearInvocations（T ... mocks）
        使用這個方法只是爲了清除調用，當存根是非平凡的。用例能夠是：
        • 你正在使用依賴注入框架來注入你的模擬。
        • 這個模擬是在有狀態的狀況下使用的。例如，一個類是獨立的，這取決於你的模擬。
        儘可能避免這種方法，不惜一切代價。只有清除調用，若是你不能有效地測試你的程序。
        類型參數：
        T  - 嘲笑的類型
        參數：
        mocks  - 嘲笑清除調用

      • verifyNoMoreInteractions

        公共靜態無效verifyNoMoreInteractions（對象 ...嘲笑）
        檢查是否有任何給定的模擬有任何未經驗證的交互。

        你能夠在驗證你的模擬以後使用這個方法 - 確保你的模擬中沒有其餘的東西被調用。

        另請參閱never()- 它更加明確，並充分傳達意圖。

        存根調用（若是調用）也被視爲交互。

        一句警告：誰作了不少經典的一些用戶，指望-運行-驗證嘲諷傾向於使用verifyNoMoreInteractions()很是頻繁，甚至在每一個測試方法。 verifyNoMoreInteractions()不建議在每一個測試方法中使用。verifyNoMoreInteractions()是交互測試工具包的一個方便的斷言。只有在相關時才使用它。濫用它會致使過分指定，不易維護的測試。你能夠在這裏找到更多的閱讀 。

        此方法還將檢測在測試方法以前發生的未經驗證的調用，例如：in setUp()，@Beforemethod或構造函數中。考慮編寫漂亮的代碼，只在測試方法中進行交互。

        例：

        //interactions mock.doSomething(); mock.doSomethingUnexpected(); //verification verify(mock).doSomething(); //following will fail because 'doSomethingUnexpected()' is unexpected verifyNoMoreInteractions(mock);
        見的例子中的javadoc  Mockito 類
        參數：
        mocks  - 待驗證

      • verifyZeroInteractions

        公共靜態無效verifyZeroInteractions（對象 ...嘲笑）
        驗證除了先前驗證的交互以外，在給定的模擬上沒有發生交互。
        這種方法具備相同的行爲 verifyNoMoreInteractions(Object...) 。
        參數：
        mocks  - 待驗證

      • doThrow

        公共靜態  Stubber  doThrow（Throwable ... toBeThrown）
        使用 doThrow() 時要與存根異常的無效方法。

        when(Object)因爲編譯器不喜歡方括號內的void方法 ，因此 須要使用不一樣的方法

        例：

        doThrow(new RuntimeException()).when(mock).someVoidMethod();
        參數：
        toBeThrown  - 當被調用的方法被調用時被拋出
        返回：
        stubber - 選擇一個存根的方法

      • doThrow

        公共靜態  Stubber  doThrow（Class <？extends Throwable > toBeThrown）
        使用 doThrow() 時要與存根異常的無效方法。

        將爲每一個方法調用建立一個新的異常實例。

        when(Object)因爲編譯器不喜歡方括號內的void方法 ，因此 須要使用不一樣的方法

        例：

        doThrow(RuntimeException.class).when(mock).someVoidMethod();
        參數：
        toBeThrown  - 當被調用的方法被調用時被拋出
        返回：
        stubber - 選擇一個存根的方法
        以來：
        2.1.0

      • doThrow

        public static  Stubber  doThrow（Class <？extends Throwable > toBeThrown，
                               Class <？extends Throwable > ... toBeThrownNext）
        與 doThrow(Class) 設置連續的異常類相同。記住要使用  doThrow() 時要存根的void方法拋出指定類的幾個異常。

        將爲每一個方法調用建立一個新的異常實例。

        when(Object)因爲編譯器不喜歡方括號內的void方法 ，因此 須要使用不一樣的方法

        例：

        doThrow(RuntimeException.class, BigFailure.class).when(mock).someVoidMethod();
        參數：
        toBeThrown  - 當被調用的方法被調用時被拋出
        toBeThrownNext  - 當被調用的方法被調用時接下來被拋出
        返回：
        stubber - 選擇一個存根的方法
        以來：
        2.1.0

      • doCallRealMethod

        public static  Stubber  doCallRealMethod（）
        使用 doCallRealMethod() 時要調用真正執行的方法。

        像往常同樣，您將閱讀部分模擬警告：面向對象的編程經過將複雜性劃分爲單獨的，特定的SRPy對象來解決更復雜的問題。部分模擬如何適應這種模式？那麼，它只是不...部分模擬一般意味着複雜性已被移動到同一個對象上的不一樣方法。在大多數狀況下，這不是您想要設計應用程序的方式。

        可是，有些狀況下，部分模擬會變得很方便：處理不能輕易更改的代碼（第三方接口，傳統代碼的臨時重構等）。可是，我不會使用部分模擬來實現新的，測試驅動的，設計的代碼。

        另請參閱javadoc spy(Object)以瞭解有關部分嘲諷的更多信息。 Mockito.spy（）是建立部分模擬的推薦方法。 緣由是它保證真正的方法被稱爲正確構造的對象，由於你負責構造傳遞給spy（）方法的對象。

        例：

        Foo mock = mock(Foo.class);
   doCallRealMethod().when(mock).someVoidMethod();

   // this will call the real implementation of Foo.someVoidMethod() mock.someVoidMethod();

        見的例子中的javadoc Mockito類

        返回：
        stubber - 選擇一個存根的方法
        以來：
        1.9.5

      • doAnswer

        公共靜態  Stubber  doAnswer（回答  ）
        使用 doAnswer() 時要與存根通用空隙的方法 Answer 。

        when(Object)因爲編譯器不喜歡方括號內的void方法 ，因此 須要使用不一樣的方法

        例：

        doAnswer(new Answer() { public Object answer(InvocationOnMock invocation) { Object[] args = invocation.getArguments(); Mock mock = invocation.getMock(); return null; }}) .when(mock).someMethod();

        見的例子中的javadoc Mockito類

        參數：
        answer  - 在調用存根方法時回答
        返回：
        stubber - 選擇一個存根的方法

      • 沒作什麼

        公共靜態  Stubber  doNothing（）
        使用 doNothing() 設置無效的方法什麼也不作。 請注意，虛擬方法嘲笑默認狀況下不作任何事情！  可是，在doNothing（）方便的狀況下，

         

        1. 連續調用一個void方法： 
          doNothing().
   doThrow(new RuntimeException()) .when(mock).someVoidMethod(); //does nothing the first time: mock.someVoidMethod(); //throws RuntimeException the next time: mock.someVoidMethod();
        2. 當你窺探真實的物體時，你想讓void方法什麼也不作： 
          List list = new LinkedList(); List spy = spy(list); //let's make clear() do nothing doNothing().when(spy).clear(); spy.add("one"); //clear() does nothing, so the list still contains "one" spy.clear();

        見的例子中的javadoc Mockito類

        返回：
        stubber - 選擇一個存根的方法

      • doReturn

        公共靜態  Stubber  doReturn（Object  toBeReturned）
        使用 doReturn() 在那些極少數狀況下，你不能使用 when(Object) 。

        注意when(Object)老是建議用於存根，由於它是參數類型安全的，而且更具可讀性（特別是在連續調用存根時）。

        如下是doReturn（）方便使用的狀況：

         

        1. 當間諜偵察真實的對象和調用真正的方法間諜帶來的反作用 
          List list = new LinkedList(); List spy = spy(list); //Impossible: real method is called so spy.get(0) throws IndexOutOfBoundsException (the list is yet empty) when(spy.get(0)).thenReturn("foo"); //You have to use doReturn() for stubbing: doReturn("foo").when(spy).get(0);
        2. 覆蓋之前的例外狀況： 
          when(mock.foo()).thenThrow(new RuntimeException()); //Impossible: the exception-stubbed foo() method is called so RuntimeException is thrown. when(mock.foo()).thenReturn("bar"); //You have to use doReturn() for stubbing: doReturn("bar").when(mock).foo();
        以上場景展現了Mockito優雅語法的折衷。請注意，情景是很是罕見的，雖然。間諜應該是零星的，壓倒一切的例外狀況很是罕見。更不用說，通常來講，被覆蓋的殘片是一種潛在的代碼味道，指出了太多的殘片。

        見的例子中的javadoc Mockito類

        參數：
        toBeReturned  - 當被調用的方法被調用時被返回
        返回：
        stubber - 選擇一個存根的方法

      • doReturn

        公共靜態  Stubber  doReturn（Object  toBeReturned，
                                Object ... toBeReturnedNext）
        相同 doReturn(Object) 但設置要返回的連續值。請記住 doReturn() 在不能使用的狀況下使用 這些罕見的場合 when(Object) 。

        注意when(Object)老是建議用於存根，由於它是參數類型安全的，而且更具可讀性（特別是在連續調用存根時）。

        如下是doReturn（）方便使用的狀況：

         

        1. 當間諜偵察真實的對象和調用真正的方法間諜帶來的反作用 
          List list = new LinkedList(); List spy = spy(list); //Impossible: real method is called so spy.get(0) throws IndexOutOfBoundsException (the list is yet empty) when(spy.get(0)).thenReturn("foo", "bar", "qix"); //You have to use doReturn() for stubbing: doReturn("foo", "bar", "qix").when(spy).get(0);
        2. 覆蓋之前的例外狀況： 
          when(mock.foo()).thenThrow(new RuntimeException()); //Impossible: the exception-stubbed foo() method is called so RuntimeException is thrown. when(mock.foo()).thenReturn("bar", "foo", "qix"); //You have to use doReturn() for stubbing: doReturn("bar", "foo", "qix").when(mock).foo();
        以上場景展現了Mockito優雅語法的折衷。請注意，情景是很是罕見的，雖然。間諜應該是零星的，壓倒一切的例外狀況很是罕見。更不用說，通常來講，被覆蓋的殘片是一種潛在的代碼味道，指出了太多的殘片。

        見的例子中的javadoc Mockito類

        參數：
        toBeReturned  - 當被調用的方法被調用時被返回
        toBeReturnedNext  - 在調用存根方法時連續調用返回
        返回：
        stubber - 選擇一個存根的方法
        以來：
        2.1.0

      • 爲了

        公共靜態  InOrder inOrder  （Object ... mocks）
        建立 InOrder 容許按順序驗證模擬的對象。 
        InOrder inOrder = inOrder(firstMock, secondMock);

   inOrder.verify(firstMock).add("was called first"); inOrder.verify(secondMock).add("was called second");
        按順序進行驗證是很是靈活的 -  您沒必要 逐個驗證全部交互，只須要驗證您有興趣測試的全部交互。

        此外，您能夠建立InOrder對象，只傳遞與按序驗證相關的模擬。

        InOrder驗證是「貪婪」的，但你幾乎不會注意到它。若是你想了解更多，請閱讀 這個維基頁面。

        從Mockito 1.8.4開始，您能夠按順序驗證NoMoreInvocations（）。閱讀更多：InOrder.verifyNoMoreInteractions()

        見的例子中的javadoc Mockito類

        參數：
        mocks  - 按順序覈實
        返回：
        InOrder對象用於按順序進行驗證

      • ignoreStubs

        public static  Object [] ignoreStubs（Object ... mocks）
        爲了驗證，忽略了給定模擬的殘留方法。有時加上 verifyNoMoreInteractions() 或驗證時有用 inOrder() 。有助於避免冗餘驗證，一般咱們對驗證存根不感興趣。

        警告，ignoreStubs()可能會致使過分使用verifyNoMoreInteractions(ignoreStubs(...)); Bear記住，Mockito不建議verifyNoMoreInteractions() 按照javadoc中概述的緣由轟擊每一個測試。verifyNoMoreInteractions(Object...) 其餘的話：全部* stubbed *方法的給定mock被標記*驗證*，以便他們不進入verifyNoMoreInteractions（）期間的一種方法。

        這種方法改變輸入模擬！這個方法只是爲了方便返回輸入模擬。

        包括在內的被忽略的存根也將被忽略用於驗證InOrder.verifyNoMoreInteractions()。看第二個例子。

        例：

        //mocking lists for the sake of the example (if you mock List in real you will burn in hell) List mock1 = mock(List.class), mock2 = mock(List.class); //stubbing mocks: when(mock1.get(0)).thenReturn(10); when(mock2.get(0)).thenReturn(20); //using mocks by calling stubbed get(0) methods: System.out.println(mock1.get(0)); //prints 10 System.out.println(mock2.get(0)); //prints 20 //using mocks by calling clear() methods: mock1.clear(); mock2.clear(); //verification: verify(mock1).clear(); verify(mock2).clear(); //verifyNoMoreInteractions() fails because get() methods were not accounted for. try { verifyNoMoreInteractions(mock1, mock2); } catch (NoInteractionsWanted e); //However, if we ignore stubbed methods then we can verifyNoMoreInteractions() verifyNoMoreInteractions(ignoreStubs(mock1, mock2)); //Remember that ignoreStubs() *changes* the input mocks and returns them for convenience.
        忽略存根可用於 驗證順序 ： 
        List list = mock(List.class);
  when(mock.get(0)).thenReturn("foo"); list.add(0); System.out.println(list.get(0)); //we don't want to verify this list.clear(); InOrder inOrder = inOrder(ignoreStubs(list)); inOrder.verify(list).add(0); inOrder.verify(list).clear(); inOrder.verifyNoMoreInteractions();
        參數：
        mocks  - 輸入模擬將被改變
        返回：
        一樣的模擬參數傳入
        以來：
        1.9.0

      • 時

        public static  VerificationMode  times（int wantedNumberOfInvocations）
        容許驗證確切的調用次數。例如： 
        verify(mock, times(2)).someMethod("some arg");
        見的例子中的javadoc  Mockito 類
        參數：
        wantedNumberOfInvocations  - 想要的調用次數
        返回：
        驗證模式

      • 至少一次

        公共靜態  驗證模式  atLeastOnce（）
        容許至少一次驗證。例如： 
        verify(mock, atLeastOnce()).someMethod("some arg");
        別名 atLeast(1) 。

        見的例子中的javadoc Mockito類

        返回：
        驗證模式

      • 至少

        公共靜態  VerificationMode  atLeast（int minNumberOfInvocations）
        容許至少x驗證。例如： 
        verify(mock, atLeast(3)).someMethod("some arg");
        見的例子中的javadoc  Mockito 類
        參數：
        minNumberOfInvocations  - 最少的調用次數
        返回：
        驗證模式

      • 最多

        公共靜態  VerificationMode  atMost（int maxNumberOfInvocations）
        容許進行最多x驗證。例如： 
        verify(mock, atMost(3)).someMethod("some arg");
        見的例子中的javadoc  Mockito 類
        參數：
        maxNumberOfInvocations  - 最大的調用次數
        返回：
        驗證模式

      • 電話

        公共靜態  VerificationMode  調用（int wantedNumberOfInvocations）
        按順序進行非貪婪驗證。例如 
        inOrder.verify( mock, calls( 2 )).someMethod( "some arg" );
        • 若是方法被調用3次不會失敗，不像時間（2）
        • 不會將第三次調用標記爲已驗證，不像atLeast（2）
        該驗證模式只能用於驗證。
        參數：
        wantedNumberOfInvocations  - 要驗證的調用次數
        返回：
        驗證模式

      • 只要

        public static  VerificationMode  only（）
        容許檢查給定的方法是惟一被調用的方法。例如： 
        verify(mock, only()).someMethod();
   //above is a shorthand for following 2 lines of code: verify(mock).someMethod(); verifyNoMoreInvocations(mock);

        也能夠看看 verifyNoMoreInteractions(Object...)

        見的例子中的javadoc Mockito類

        返回：
        驗證模式

      • 時間到

        公共靜態  VerificationWithTimeout  超時（長毫秒）
        容許超時驗證。它會致使驗證等待指定的時間段進行指望的交互，而不是當即失敗，若是尚未發生。可能對併發條件下的測試有用。

        這不一樣於after()在（）以後將等待整個週期，除非最後的測試結果是早期知道的（例如，若是一個never（）失敗），而timeout（）將在驗證經過後儘早中止，當使用時產生不一樣的行爲與時間（2），例如，能夠經過，而後失敗。在這種狀況下，超時將在時間（2）經過後當即傳遞，而在時間（2）失敗後運行，而後失敗。

        這個功能應該不多使用 - 找出測試你的多線程系統的更好方法。

        //passes when someMethod() is called within given time span verify(mock, timeout(100)).someMethod(); //above is an alias to: verify(mock, timeout(100).times(1)).someMethod(); //passes as soon as someMethod() has been called 2 times before the given timeout verify(mock, timeout(100).times(2)).someMethod(); //equivalent: this also passes as soon as someMethod() has been called 2 times before the given timeout verify(mock, timeout(100).atLeast(2)).someMethod(); //verifies someMethod() within given time span using given verification mode //useful only if you have your own custom verification modes. verify(mock, new Timeout(100, yourOwnVerificationMode)).someMethod();
        見的例子中的javadoc  Mockito 類
        參數：
        millis  - - 以毫秒爲單位的時間跨度
        返回：
        驗證模式

      • 後

         （long millis）以後的公共靜態  VerificationAfterDelay
        容許在給定的時間內進行驗證。它會致使驗證等待指定的時間段進行所需的交互，而不是當即失敗（若是還沒有發生）。可能對併發條件下的測試有用。

        這不一樣於timeout()在（）以後等待整個週期，而timeout（）將在驗證經過後當即提早中止，在與時間（2）一塊兒使用時產生不一樣的行爲，例如，能夠經過而後失敗。在這種狀況下，超時會在時間（2）經過後當即傳遞，而在以後的時間將運行整個時間，哪一個時間點將失敗，由於時間（2）失敗。

        這個功能應該不多使用 - 找出測試你的多線程系統的更好方法。

        還沒有實施以使用InOrder驗證。

        //passes after 100ms, if someMethod() has only been called once at that time. verify(mock, after(100)).someMethod(); //above is an alias to: verify(mock, after(100).times(1)).someMethod(); //passes if someMethod() is called *exactly* 2 times after the given timespan verify(mock, after(100).times(2)).someMethod(); //passes if someMethod() has not been called after the given timespan verify(mock, after(100).never()).someMethod(); //verifies someMethod() after a given time span using given verification mode //useful only if you have your own custom verification modes. verify(mock, new After(100, yourOwnVerificationMode)).someMethod();
        見的例子中的javadoc  Mockito 類
        參數：
        millis  - - 以毫秒爲單位的時間跨度
        返回：
        驗證模式

      • validateMockitoUsage

        公共靜態無效validateMockitoUsage（）
        首先，若是遇到任何問題，我建議您閱讀Mockito FAQ：https： //github.com/mockito/mockito/wiki/FAQ

        若有疑問，您也能夠發送到mockito郵件列表：http：//groups.google.com/group/mockito

        validateMockitoUsage() 明確驗證框架狀態以檢測Mockito的無效使用。不過，這個功能是可選的，由於Mockito始終驗證使用狀況...可是有一個小問題須要閱讀。

        錯誤使用的例子：

        //Oops, thenReturn() part is missing: when(mock.get()); //Oops, verified method call is inside verify() where it should be on the outside: verify(mock.execute()); //Oops, missing method to verify: verify(mock);
        若是你濫用Mockito會拋出異常，這樣你就知道你的測試是否寫得正確。問題是Mockito  在下一次 使用框架時會進行驗證（例如，下一次驗證，存根，調用模擬等）。可是，即便在下一次測試中可能會拋出異常，異常 消息中 也會包含一個帶有缺陷位置的可導航堆棧跟蹤元素。所以，您能夠點擊並找到Mockito被濫用的地方。

        有時候，你可能想明確地驗證框架的用法。例如，其中一個用戶想要投入validateMockitoUsage()他的@After方法，以便他在誤用Mockito時當即知道。沒有它，他會早在下一次他就使用這個框架就知道了。validateMockitoUsage()進入的另一個好處@After是，jUnit跑步者和規則在測試方法中總會失敗，而普通的「下一次」驗證可能會使下一個測試方法失敗。但即便JUnit可能會將下一個測試報告爲紅色，也不要擔憂，只需單擊異常消息中的可導航堆棧跟蹤元素便可找到您誤用mockito的地方。

        內置runner MockitoJUnitRunner和規則：MockitoRule在每一個測試方法以後，執行validateMockitoUsage（）。

        請記住，一般狀況下，您沒必要validateMockitoUsage() 在下一次觸發框架驗證時就足夠了，這主要是由於加強了異常消息和可點擊的缺陷位置。可是，若是您已經擁有足夠的測試基礎架構（好比您本身的全部測試的運行者或基類），那麼我會推薦使用validateMockitoUsage（），由於添加了一個特殊的操做來實現@After零成本。

        見的例子中的javadoc Mockito類

      • withSettings

        public static  MockSettings  withSettings（）
        容許使用附加的模擬設置進行模擬建立。

        不要常用它。考慮編寫使用簡單模擬的簡單測試。重複我以後：簡單的測試推簡單，KISSy，可讀和可維護的代碼。若是你不能以簡單的方式編寫測試 - 重構測試中的代碼。

        模擬設置的例子：

        //Creates mock with different default answer & name Foo mock = mock(Foo.class, withSettings() .defaultAnswer(RETURNS_SMART_NULLS) .name("cool mockie")); //Creates mock with different default answer, descriptive name and extra interfaces Foo mock = mock(Foo.class, withSettings() .defaultAnswer(RETURNS_SMART_NULLS) .name("cool mockie") .extraInterfaces(Bar.class));
        MockSettings 已經出現了兩個緣由。首先，當需求到來時，很容易添加另外一個模擬設置。其次，爲了可以結合不一樣的模擬設置而不須要引入大量的重載模擬（）方法。

        查看javadoc MockSettings瞭解可能的模擬設置。

         

        返回：
        模擬設置實例與默認值。

      • 描述

        public static  VerificationMode  description（String  description）
        若是驗證失敗，則添加要打印的說明。 
        verify(mock, description("This will print on failure")).someMethod("some arg");
        參數：
        description  - 描述打印失敗。
        返回：
        驗證模式
        以來：
        2.1.0

      • mockitoSession

        @Incubating 
public static  MockitoSessionBuilder  mockitoSession（）
        MockitoSession  是一個可選的強烈推薦的功能，經過消除樣板代碼和添加額外的驗證來幫助推進清潔測試。
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程