上一章節我們主要講的是在執行test case之前，在recorded階段進行“期望”（可能會有些看不懂這個“期望”，實際上就是指對被mock的方法進行錄製，希望被引用的方法返回自己設定的值，或者欄位設定為自己設定的值）。這些“期望”是否真的在test case執行時發生了？一種是隱性的驗證（如果是嚴格的型別，即在Expectations block中，或者是進行了引用次數times的限制，如果這些“期望”沒有執行或者被引用的話，那麼就會報AssertionError），另一種就是沒有根本沒有進行驗證（如果是非嚴格型別，並且沒有進行引用次數times的限制），當然第二種方式是不提倡的。

接下來我們將介紹使用Jmockit提供的第二種型別的mock API——Jmockit Verifications API，它允許我們使用顯示的方式來驗證在test case執行的時候，我們所期望的mock是否真的被引用了。

被測類依舊是序言中的MyBussinessService類，先將官網上的程式碼貼上，然後一起理解

package jmockit.tutorial.domain;

import java.util.*;
import static java.util.Arrays.*;
import org.apache.commons.mail.*;
import jmockit.tutorial.persistence.*;

import org.junit.*;
import mockit.*;

public final class MyBusinessService_VerificationsAPI_Test
{
   @Tested MyBusinessService service; // instantiated automatically
   @Mocked(stubOutClassInitialization = true) Database onlyStatics;
   @Capturing Email email; // concrete subclass mocked on demand, when loaded

   final EntityX data = new EntityX(5, "abc", "
 
[email protected]");

   @Test
   public void doBusinessOperationXyzPersistsData() throws Exception
   {
      // No expectations recorded in this case.

      service.doBusinessOperationXyz(data);

(2)   new Verifications() {{ Database.persist(data); }};
   }

   @Test
   public void doBusinessOperationXyzFindsItemsAndSendsNotificationEmail() throws Exception
   {
      // Invocations that produce a result are recorded, but only those we care about.
      new NonStrictExpectations() {{
(1)      Database.find(withSubstring("select"), (Object[]) null);
         result = asList(new EntityX(1, "AX5", "
 
[email protected]"));
      }};

      service.doBusinessOperationXyz(data);

      new VerificationsInOrder() {{
(3)      email.addTo(data.getCustomerEmail());
(4)      email.send();
      }};
   }
}

通過上面的例子指出，有兩種方式可以使我們進行的“期望”是non-strict expectations型別的：第一種，就是乾脆不要任何expectation block，就像第一個測試方法一樣（doBussinessOperationXyzPersistsData()）;第二種就是在一個NonStrictExpectations block中進行指定“期望”，第二個測試方法就是一個例子。在第一個測試例子中，產品程式碼中被mock型別的所有呼叫都能被不限制的引用，但是non-void的方法根據自身的返回型別會預設返回一個合適的值（這個在後面的章節會提到），很顯然，這是不合適的，所以在一個expecation block裡面進行一些“期望”是有必要的。混合著使用嚴格型（strict-expectations）和非嚴格型（non-strict expectations）也是可以的，通過在被mock的型別前新增@NonStrict，或者在Expectations block中進行“期望”的時候使用notStrict方法。

當我們使用了non-strict expectations，在回放階段呼叫的被mock的方法或者建構函式是否真的走了我們的“期望”而不是程式碼的真實邏輯，是不會立即進行驗證的（除非顯示的使用了times等呼叫次數限制）。這些非嚴格型的呼叫，在錄製的時候被指定了一個特定的返回值，甚至是一個異常，在test case進行回放的時候都會產生作用。

事實是在non-strict expectations中進行顯示的錄製後允許測試方法通過了，就足以證明被測方法做的是正確的（因為在非嚴格型裡面進行顯示錄製，必定是錄製了返回值，甚至是指定了呼叫的次數，這就包括了驗證了），在第二個測試例子中，如果將result=asList(…………)給註釋掉，那麼這個test case很有可能會fail掉，因為當其他的函式或者型別需要用到這個result的時候（只是預設的值，可能不能滿足要求），或者是呼叫的驗證失敗了。在這個例子中，如果真的去掉了result=asList(…………)，那麼一個額外email.setMsg(withNotEqual(""))驗證就需要新增到另外2個已有的驗證中間。然而，在很多情況下，你需要確定被錄製的引用至少被運行了1次，那麼我們可以通過在錄製的時候，使用minTimes=1來做到這一點。
non-strict expectations的另一個優勢是他們可以顯示的驗證測試方法是否正確。這些verifications和錄製有點像，但是是在Verification block中（或者像例子中的VerificationsInOrder，這個是Verification的子類，inorder表明是按照順序進行驗證的，順序錯了，test case就會fail掉，這個會在以後的章節進行介紹），這些驗證是在測試方法執行之後進行驗證的，也就是在回放階段結束之後。而有times（或者maxTimes，minTimes）的，是在回放階段就會進行驗證。

從語法上來說，一個verification block是很像一個expectation block的。次數的限制對於測試方法的驗證是很有用的，也是必須用的（要不然光mock了，測試通過了，進行錄製的方法到底有沒有執行都不知道），前面就提到過使用times，minTimes，以及maxTimes這三個欄位，例如，如果一個被mock類中的方法在測試方法中從來沒有被呼叫過，那麼使用times=0（或者如果願意使用maxTimes=0）來進行驗證是十分正確的。

例子中的程式碼宣告的型別，使用了新的方式（這裡只是簡單的介紹一下，詳細的會在以後進行補充，如果急切需要了解，可以參考官方的API）：

 @Tested MyBusinessService service; // instantiated automatically
 @Mocked(stubOutClassInitialization = true) Database onlyStatics;
 @Capturing Email email; // concrete subclass mocked on demand, when loaded

 @NonStrict SimpleEmail email; // calls to setters are unimportant, so we make it non-strict

Verfications API就簡單的介紹到這，預告Jmockit示例三部曲的第三部——按我自己的思路走。