對於單元測試，模擬數據層還是使用像德比這樣的嵌入式數據庫會更好？通過模擬數據層或使用嵌入式數據庫進行單元測試

我知道這也取決於測試的目的。但是如果我和德比一起去，我不必嘲笑所有的對象，我認爲這會更容易。另一方面，我明白這更多的是集成測試。那麼單元測試更常見哪一種？

感謝。

根據意見更新：

所以我現在德比配置的，但我的經理堅持使用EasyMock的。我們使用jpa，我們有大約20個表=>數據模型。那麼對於像項目模型這樣的每種方法，我是否應該爲其所有方法指定mockedProject的返回類型？像getProjectName（），getProjectId（）等？我也應該嘲笑持久管理器對象。我認爲這只是配置像德比這樣的嵌入式數據庫而已。

來源

2012-07-18 Sara

你的更新在技術上是另一個問題，所以只有幾句話。你不應該模擬值對象（我假設'Project'是一個實體）。而是模擬行爲。使用JPA嘲諷'EntityManager'應該足夠了。 – 2012-07-18 21:58:23

更詳細的問題：http://stackoverflow.com/questions/11551905/unit-testing-a-method-with-easymock – Sara 2012-07-18 23:34:18

看到，如果你正在使用JPA，您不必嘲笑你的項目的對象，因爲他們可能只是啞POJO的，對吧？你需要模擬的只是持久性管理器對象（EntityManager）。在最簡單的情況下（如果你使用Mockito或Easymock和'niceMock'），你可能只需要創建模擬並注入它，就是這樣。根據你在測試什麼，你可能會想要做的比這更多：驗證一個save或merge方法被調用，指定它是一個get調用返回一個特定的項目對象等

嘲諷EntityManager具有以下優點：

運行速度非常快 - 甚至比嵌入式數據庫快得多。這些測試將會進行很多次，所以重要的是他們不要太過擔子。
您不需要填充真實的數據庫。儘管您可能需要爲某些集成測試執行此操作，但很難提供涵蓋所有所需場景的數據庫。通過嘲笑，您可以在測試本身中創建您想要的特定場景。
您可能想要測試某些在現實中很難發生的情況，例如IO錯誤或數據庫中已存在但違反了某些約束條件的數據。嘲笑，你只是告訴模擬在調用方法時拋出異常。連接到一個真實的數據庫（甚至是嵌入式的），要想實現它，將是非常困難的（如果不是不可能的話）。

嘲笑POJO沒有這些好處。將POJO的代碼作爲嘲諷的POJO執行同樣快。填充POJO可能有點痛苦，但不如建立模擬POJO的行爲。而且由於POJO通常不具有很多外部依賴性，所以很少需要第三個好處。

來源

2012-07-18 23:06:29 jhericks

非常感謝。這是我正在尋找的。我對嘲笑不太瞭解。我會發布另一個問題，並通過鏈接在這裏。如果你稍後可以看看，我將不勝感激。謝謝。 – Sara 2012-07-18 23:15:57

如果你有時間，你可以看看這個：http://stackoverflow.com/questions/11551905/unit-testing-a-method-with-easymock – Sara 2012-07-18 23:35:01

對於單元測試，我會推薦嘲笑你的數據層。這就清楚地表明你沒有測試數據層的功能，並且也增加了單元測試的速度。

進行集成測試時，您應該將實時數據庫連接到您的數據層，我傾向於使用與生產中使用的數據庫相同類型的數據庫來限制稍後引入新錯誤的風險。另外，我建議讓每個測試都構建自己的測試數據並將其刪除，因爲這可確保每個測試不受與其他測試案例中測試數據交互的影響。

來源

2012-07-18 21:36:40

首先，如果你使用單元測試的外部組件（如數據庫，文件系統等），他們不能再被稱爲單元測試，但集成測試來代替。

在另一方面引述經典Mocks Aren't Stubs說：

假對象實際上有工作的實現，但通常需要一定的快捷方式，這使得它們不適合用於生產（一個內存數據庫是一個好例子）。

並沒有什麼錯在單元測試中使用假貨。

這就是說我建議使用一些快速和簡單的內存數據庫，如h2。嘲諷DataSource，Connection,ResultSet,PreparedStatement ......只是不值得痛苦。

也

來源

2012-07-18 21:39:55

問題不在於單元測試數據層，所以你不需要模擬所有的內部它只有它自己用於測試代碼的其他部分的層。 – 2012-07-18 21:48:27

Plz檢查我的更新。感謝您的回覆。 – Sara 2012-07-18 21:54:03

通過模擬數據層或使用嵌入式數據庫進行單元測試

回答

也

相關問題