爲什麼我會使用MockRunner而不是正常/手動依賴注入？

Question

在我們的公司，我們有一個服務層，它接受一些請求XML，通過JDBC訪問各種存儲過程（SP），處理數據並響應一些響應XML。最近人們開始在他們的JUnit測試中採用MockRunner來模擬SP的響應。該代碼設置從SP的使用Mockrunner用嘲笑的迴應看起來可怕（這是第一次隨機測試類我打開）：

MockConnection connection = new MockConnection(); 
    MockContextFactory.setAsInitial(); 
    InitialContext context = new InitialContext(); 
    context.rebind(READ_PAYMENT_DATA_SOURCE, getDS()); 
    getDS().setupConnection(connection); 
    m_csStatementHandler = connection.getCallableStatementResultSetHandler(); 
    m_csStatementHandler.clearResultSets(); 
    m_csStatementHandler.clearCallableStatements(); 
    m_csStatementHandler.setExactMatch(false); 
m_csStatementHandler.prepareReturnsResultSet(READ_PAYMENT, true); 
    m_csStatementHandler.setExactMatch(false); 
    m_csStatementHandler.setExactMatchParameter(false); 
    Map parameterMap = new HashMap(); 
    parameterMap.put(new Integer(1), null); 
    parameterMap.put(new Integer(2), null); 
    parameterMap.put(new Integer(3), null); 
    parameterMap.put(new Integer(4), null); 
    m_csStatementHandler.prepareOutParameter(READ_PAYMENT, parameterMap); 
    //Set up the cursor of applications for return. 
    MockResultSet resultApps = m_csStatementHandler.createResultSet(); 

    resultApps.addRow(getPaymentSchedule("E", "Monthly", new Short("1"),null,null,null,null,null,null,null)); 
    resultApps.addRow(getPaymentSchedule("A", "Weekly", new Short("1"),null,null,null,null,null,null,null)); 
    resultApps.addRow(getPaymentSchedule("R", "Yearly", new Short("1"),null,null,null,null,null,null,null)); 
    resultApps.addRow(getPaymentSchedule("S", "Weekly", new Short("1"),null,null,null,null,null,null,null)); 
    resultApps.addRow(getPaymentSchedule("W", "Monthly", new Short("1"),null,null,null,null,null,null,null)); 

    MockResultSet[] results = new MockResultSet[1]; 
    results[0] = resultApps; 
    m_csStatementHandler.prepareResultSet(READ_PAYMENT, resultApps); 

上面的代碼是可怕的原因有很多，但它清楚地表明瞭複雜性和從存儲過程設置響應的開銷。

迄今爲止，我一直使用手動滾動依賴注入來注入實際調用存儲過程的類。我所要做的就是創建一個模擬SP調用者類（負責SP的實際執行）並設置我想要的響應數據。我對這種技術非常滿意，因爲它的數據集中而不是擔心實現細節，所以它比上面簡單得多。但我的問題是，你想什麼時候使用MockRunner？單元測試看起來有些過分，所以我猜測它更適合集成或系統測試嗎？即使如此，它仍然使我更容易使用DI框架來交換SP調用方類，然後爲每個存儲過程調用設置上述所有代碼。請指教！謝謝

Answer 1

最終你正在研究一般嘲笑背後的哲學。我會給你我的兩分錢，但我也會提及你任何主要的嘲笑圖書館，這可能會爲他們自己的存在提供很好的理由。以Mockito爲例。

測試/模擬社區通常會區分手動滾動（通常稱爲「存根」（靜態，手寫類）和「模擬」（動態的，運行時生成的類） ）。

嘲笑的好處是相當大的相比，只是存根。許多測試人員爲了測試的目的而着迷於編寫接口和/或子類具體類的實現。要做到這一點，通常需要實現所述類/接口的所有方法，即使你只是想測試一個特定的方法。

模擬讓你可以通過定義你想要賦予行爲的方法來解決這個問題，而且功能強大。另外，模擬允許你改變從一個測試到下一個測試的行爲。要做到這一點與存根，你必須寫一個全新的存根類。

從嘲笑庫到庫的語法都有所不同。有些人可能會發現比其他人更可讀。我目前最喜歡的是Mockito，因此是早期的參考，但它們隨着時間推移而發展。這可能是值得確定的，爲什麼你的組織使用嘲笑套件，它是否是另一個可能仍然滿足你的需求以及更具可讀性。

希望您的測試編寫者將常見行爲引入測試設置方法（如JUnit的@Before），因此您無需繼續在各處看到模擬創建和常見初始化。