轉載地址：http://blog.csdn.net/ultrani/article/details/8993364

JMockit是google code上面的一個java單元測試mock專案，她很方便地讓你對單元測試中的final類,

JMockit的測試方式可以通過下面2個途徑實現

一.根據用例的測試路徑，測試程式碼內部邏輯

        對於這種情景，可以使用jmockit的基於行為的mock方式。在這種方式中，目的是測試單元測試及其依賴程式碼的呼叫過程，驗證程式碼邏輯是否滿足測試路徑。  由於被依賴程式碼可能在自己單測中已測試過，或者難以測試，就需要把這些被依賴程式碼的邏輯用預定期待的行為替換掉，也就是mock掉，從而把待測是程式碼隔離開，這也是單元測試的初衷。 這種方式和白盒測試接近。

二.根據測試用例的輸入輸出資料，測試程式碼是否功能執行正常。

        對於這種情景，可以使用jmockit基於狀態的mock方式。目的是從被測程式碼的使用角度出發，結合資料的輸入輸出來檢驗程式執行的這個正確性。使用這個方式，需要把被依賴的程式碼mock掉，實際上相當於改變了被依賴的程式碼的邏輯。通常在整合測試中，如果有難以呼叫的外部介面，就通過這個方式mock掉，模擬外部介面。 這種方式有點像黑盒測試。

下面根據一個簡單例子簡單介紹JMockit的幾個常用測試場景和使用方法。

       被測試類：一個猜骰子點數的類。new Guess(int n)時候指定最大猜數次數，並且生成實際點數。在n次猜測內猜中則輸出成功，n次猜測失敗後通過failHandle()輸出錯誤。結果輸出通過GuessDAO來儲存。但GuessDAO還沒實現。

1. /** 在n次機會隨機猜骰子點數 ,結果儲存到資料庫中 */
2.     publicclass Guess {  
3.         privateint maxTryTime;                         // 最大重試次數
4.         privateint tryTime = 0;                        // 當前重試次數
5.         privateint number = (int) (Math.random() * 6); // 目標數字
6.         private GuessDAO guessDAO;                      // 持久化依賴
7.         public Guess(int maxRetryTime) {               
8.             this.maxTryTime = maxRetryTime;  
9.         }  
10.         publicvoid doit() {  
11.             while (tryTime++ < maxTryTime && !tryIt()) {  
12.                 // 到達最大嘗試次數仍不成功則呼叫handle
13.                 if (tryTime == maxTryTime) {  
14.                     failHandle();  
15.                 }  
16.             }  
17.         }  
18.         publicboolean tryIt() {                        // 最壞情況下呼叫maxRetryTime次tryIt(),猜中則儲存資訊
19.             if (number == randomGuess()) {  
20.                 guessDAO.saveResult(true, number);  
21.                 returntrue;  
22.             }  
23.             returnfalse;  
24.         }  
25.         publicvoid failHandle() {                      // 失敗處理，猜不中時呼叫
26.             guessDAO.saveResult(false, number);  
27.         }  
28.         privateint randomGuess(){                      // 猜的隨機過程
29.             return (int) (Math.random() * 6);  
30.         }  
31.         publicvoid setGuessDAO(GuessDAO guessDAO) {  
32.             this.guessDAO = guessDAO;  
33.         }  
34.     }  

下面通過3個測試用例來說明如何使用jmockit

以下程式碼基於jmockit1.0 左右版本，新版去廢除了一些功能（如@Mocked不能修飾成員）

1. 測試當沒有一次猜中時，程式碼邏輯如何執行。

先上測試程式碼：

1. publicclass GuessTest {  
2.     @Tested// 表明被修飾例項是將會被自動構建和注入的例項
3.     Guess guess = new Guess(3);  
4.     @Injectable// 表明被修飾例項將會自動注入到@Tested修飾的例項中，並且會自動mock掉，除非在測試前被賦值
5.     GuessDAO guessDAO;  
6.     /** 
7.      * 連續3次失敗 
8.      */
9.     @Test
10.     publicvoid behaviorTest_fail3time() {  
11.         new Expectations() {        // Expectations中包含的內部類區塊中，體現的是一個錄製被測類的邏輯。
12.             @Mocked(methods="tryIt")  // 表明被修飾的類對tryIt()方法進行mock。
13.             Guess g;  
14.             {  
15.                 g.tryIt();             // 期待呼叫Guess.tryIt()方法
16.                 result = false;        // mock掉返回值為false（表明猜不中）
17.                 times = 3;             // 期待以上過程重複3次
18.                 guessDAO.saveResult(false, anyInt); // 期待呼叫guessDAO把猜失敗的結果儲存
19.             }  
20.         };  
21.         guess.doit();               // 錄製完成後，進行實際的程式碼呼叫，也稱回放(replay)
22.     }  
23. }  

說明下這個測試程式碼的目的： 測試行為是guess.doit(),程式碼期望在呼叫doit()函式後，會發生：
        1.呼叫tryIt，並把結果mock為false；
        2.重複第一步3次；
        3.把結果通過guessDAO儲存。即呼叫3次均猜錯數字

        可以看出，JMockit在基於行為的測試中，體現3個步驟。第一個是指令碼錄製，也就是把期望的行為記錄下來。在上面例子中，在Expectation內部類的區塊中的程式碼就是期待發生的行為。第二是回放，也就是guess.doit()觸發的過程。第三是檢驗，在這裡沒有確切體現出，但是的確發生著檢驗：假設doit方法呼叫後，程式碼的邏輯沒有符合錄製過程中的指令碼的行為，那麼測試結果失敗(其實Jmockit有專門的Verifications做檢驗，但是這裡Expecation已經包含了這個功能，如果用NonStrictExpecation就需要有檢驗塊)。

        再介紹下這段程式碼中用到的各個JMockit元素（結論源自文件及自己程式碼測試）：

@Tested和@Injectable: 對@Tested物件判斷是否為null，是則通過合適構造器初始化，並實現依賴注入。呼叫構造方法時，會嘗試使用@Injectable的欄位進行構造器注入。普通注入時，@Injectable欄位如果沒有在測試方法前被賦值，其行為將會被mock成預設值(靜態方法和建構函式不會被mock掉)。Injectable最大作用除了注入，還有就是mock的範圍只限當前註釋例項。一句話：@Injectable的例項會自動注入到@Tested中，如果沒初始賦值，那麼JMockit將會以相應規則初始化。

@Mocked:@Mocked修飾的例項，將會把例項對應類的所有例項的所有行為都mock掉（無論構造方法，還是private，protected方法，夠霸氣吧）。在Expectation區塊中，宣告的成員變數均預設帶有@Mocked，但是本例沒有省略，是因為@Mocked會mock掉所有方法，而回放的程式碼中doit函式我們是不希望它也被mock，所以通過method="tryIt"來設定被mock的類只對tryIt方法進行mock。

Expectations:這是錄製期望發生行為的地方。result和times都是其內定成員變數。result可以重定義錄製行為的返回值甚至通過Delegate來重定義行為，times是期待錄製行為的發生次數。在Expectations中發生的呼叫，均會被mock。由於沒定義result，所以guessDAO.saveResult()呼叫的結果返回空。

2. 當多次失敗後，最後一次猜數成功時，程式碼邏輯如何執行。

在上面的測試程式碼中，加多一個測試方法：

1. /** 
2.   * 兩次失敗，第三次猜數成功 
3.   */
4.  @Test
5.  publicvoid behaviorTest_sucecess() {  
6.      new Expectations(Guess.class) {                          // 建構函式可以傳入Class或Instance例項
7.          {     
8.              guess.tryIt();  
9.              result = false;  
10.              times=2;  
11.              invoke(guess, "randomGuess", new Object[]{});    // invoke()能呼叫私有方法
12.              result = (Integer)getField(guess, "number");     // getField()能操作私有成員
13.              guessDAO.saveResult(true, (Integer)getField(guess, "number"));  
14.          }  
15.      };  
16.      guess.doit();  
17.  }  

        第二個測試用例是期待先猜2次失敗，第3次猜中。

        所以錄製中會先呼叫2次tryIt並返回false，在發生第3次呼叫時，通過invoke呼叫私有方法randomGuess，並期待其返回被測例項的私有成員number，通過這種作弊的方式，自然肯定能在第三次猜中數字。最後期待guessDAO把結果儲存。

通過以上2個基於行為mock的例子，應該對JMockit如何測試程式碼內部邏輯有了解了吧。下面再對基於狀態的mock介紹：

3. 模擬正常猜骰子，觀察輸出猜中的概率

再加入第三各測試方法：

1. /** 
2.  * 模擬正常執行,計算抽中概率，把DAO mock掉 
3.  */
4. @Test
5. publicvoid stateTest_mockDAO() {  
6.     final Map<Integer, Integer> statMap = new HashMap<Integer, Integer>(); // statMap.get(0)為猜中次數，statMap.get(1)為失敗次數
7.     statMap.put(0, 0);  
8.     statMap.put(1, 0);  
9.     guessDAO = new MockUp<GuessDAO>() {            // MockUp用來定義新的程式碼邏輯
10.         @SuppressWarnings("unused")  
11.         @Mock
12.         publicboolean saveResult(boolean isSuccess, int n) {  
13.           if (isSuccess) {  
14.               statMap.put(0, statMap.get(0)+1);  
15.               System.out.println("you guess it! dice:" + n);  
16.           } else {  
17.               statMap.put(1, statMap.get(1)+1);  
18.               System.out.println("you didn't guess it. dice:" + n);  
19.           }  
20.           returntrue;  
21.         }  
22.     }.getMockInstance();    
23.     for (int i=0; i<1000; i++) {  
24.         Guess guess = new Guess(3);  
25.         guess.setGuessDAO(guessDAO);  
26.         guess.doit();  
27.     }  
28.     System.out.println("hit" + statMap.get(0));  
29.     System.out.println("not hit" + statMap.get(1));  
30.     double rate =((double) statMap.get(0)) / (statMap.get(0)+statMap.get(1));  
31.     System.out.println("hit rate=" + rate);  
32. }  

        第三個用例目的是，測試在指定嘗試次數下猜中數字的概率。這就不再盯著程式碼內部邏輯，而從整體功能角度進行測試，把內部無法呼叫的的依賴介面mock掉。

        程式碼中對GuessDAO的儲存方法進行了重定義。讓其直接從控制帶輸出訊息。

        通過這種方式，不僅可以進行功能黑盒測試，還可以儘快地讓測試程式碼跑起來。

        MockUp中的泛型型別是被重定義的類，重定義的方法需要和原類中的方法簽名一致。但是，static方法可以省區static關鍵字。如：

1. new MockUp<Calendar>() {  
2.     @Mock
3.     public Calendar getInstance() {  
4.         return calendar1;  
5.     }  
6. };  

        至此，通過三個例子，把JMockit的2個測試方式簡單介紹了。但是JMockit的功能不僅如此，詳細能請檢視官方文件和例項。

=============

過程中遇到還未解決的疑問：

1. 基於行為的mock，需要對回放的類的具體型別類mock，沒法針對父類型別mock？

1. Guess g = new Guess(3);  
2. new Expectations() {  
3.             @Mocked(methods="tryIt")  
4.             GuessParent mg;      // 對Guess父類進行mock
5.             {  
6.                 mg.tryIt();result=true;  
7.             }  
8.         };  
9. g.doit();  

2. 基於行為的動態mock， 文件說： If the Class object for a given class is passed, the methods and constructors defined in that class are considered for mocking,but not the methods and constructors of its super-classes. If an instance of a given class is passed, then all methods defined in the whole class hierarchy, from the concrete class of the given instance up to (but not including) Object, are considered for mocking; the constructors of these classes, however, are not (since an instance was already created). 粗體的不是很理解，是說mock的父類的方法和建構函式不被mock？但測試結果卻不是這樣

其他Mock框架與jmockit對比