如何爲複雜的底層實體編寫測試用例？

我正在爲現有系統編寫單元測試用例。底層類的體系結構本身非常複雜。如何爲複雜的底層實體編寫測試用例？

Blockquote RequestHanndler ==> processes ==> Order ===>依賴於==>服務層==連接到==> DB層。

我正在爲RequestHandler寫一個測試用例。測試方法（doProcess()）創建Order類的新實例。 Order類本身對服務層的依賴非常緊密。我想創建一個原子測試用例，所以不會執行任何其他代碼層。

什麼應該爲這些scenrios創建測試用例的最佳過程？

2011-11-07 Vijay Shanker Dubey

「Order類本身所具有的業務層上非常緊張的依賴。」 - 爲什麼？ – blank

@Bedwyr這不是我的設計。這就是這樣，我沒有任何控制權。 –

當你想爲緊密耦合的代碼編寫單元測試時，它可能會有點複雜。爲了使uni測試更容易，您應該更好地依賴抽象，而不是真正的實現。例如。 Order類應該不依賴於服務層的實際實現，而應該引入一個更容易模擬的接口，而不是可能設置爲final的類。

由於您的RequestHandler負責創建訂單實例，因此您必須提供一種在單元測試中模擬訂單類的方法。簡單的方法是創建一個簡單地創建一個新訂單實例的受保護方法。

protected Order createOrder(String someParam) { 
    return new Order(someParam); 
}

在您的單元測試中，您現在可以擴展該類並覆蓋工廠方法。使用Mockito這看起來像：

protected Order createOrder(String someParam) { 
    Order order = Mockito.mock(Order.class); // create mock object 
    // configure mock to return someParam when 
    // String Order#getSomeParam() gets invoked 
    Mockito.doReturn(someParam).when(order).getSomeParam(); 
    return order; 
}

來源

2011-11-07 08:36:53

這種系統的單元測試的典型方法是嘲弄。有幾個Java模型框架。我個人使用EasyMock，但也有其他人。

所以，我認爲你應該嘗試首先測試請求處理程序的邏輯。您應該模擬訂單（即使用模型框架創建虛擬，而不是實際的訂單實例）。當測試這個圖層時會更深入並開始測試內部圖層。

其他策略是從下往上，即先測試內層。這種策略可能是「正確的」，但它不會讓你的經理獲得快速的結果，因爲管理者通常喜歡看到「大」的圖景，很少進入細節。

底線：祝你好運。

來源

2011-11-07 08:23:17 AlexR

我想創建一個Order類的模擬版本，但我無法確定任何讓RequestHandler使用MockedOrder的方法。請建議。 –

如何爲複雜的底層實體編寫測試用例？

回答

相關問題