爲DAO編寫測試

Question

我目前被分配爲項目編寫測試，是否需要爲DAO類編寫測試？

Answer 1

這取決於:-)

如果你的DAO類僅包含獲取從DB實體所需的代碼，這是更好地測試他們在不同的集成測試*。要進行單元測試的代碼是您可以使用模擬DAO進行單元測試的「業務邏輯」。

[更新] E.g.與EasyMock你可以很容易地爲特定的類建立一個模擬（使用它的類擴展，甚至可以模擬具體的類），將它配置爲從特定的方法調用中返回一個特定的對象，並將它注入到你的類中進行測試。

EasyMock網站似乎現在正在運行，希望它會很快回來 - 然後您可以檢查文檔，這是恕我直言，相當乾淨徹底，有很多代碼示例。在你的問題中沒有太多細節，我不能給出更具體的答案。如果OTOH，DAO也包含業務邏輯，那麼你最好的選擇 - 如果你能做到這一點 - 將重構它們並將業務邏輯從DAO中移出，那麼你可以應用先前的策略。

但底線是，始終牢記單元測試座右銘「測試可能會破壞的所有東西」。換句話說，我們需要優先考慮我們的任務，並集中精力編寫能夠以最小的努力提供最大收益的測試。首先爲最關鍵的，最具有bug風險的代碼部分編寫單元測試。在你看來，代碼是非常簡單的，不可能破壞的是代碼。當然，建議您向具有代表性的具體代碼諮詢經驗豐富的開發人員 - 他們可能知道並注意到您可能沒有意識到的陷阱和問題。

*單元測試應該是輕量級的，快速和儘可能與環境隔離。因此，包含調用真實數據庫的測試不是單元測試，而是集成測試。儘管技術上它們可以用JUnit（和例如DbUnit）來構建和執行，但它們比真正的單元測試要複雜得多，速度要慢幾個數量級。有時這會使得它們不適合在每次小代碼更改後執行，因爲常規單元測試可能（並且通常應該）被使用。

Answer 2

是的，你應該爲DAO編寫單元測試。

這些單元測試可以使用內存數據庫。例如見：HyperSQL

條關於如何使用的HyperSQL寫持久性單元測試中的Java：

http://www.mikebosch.com/?p=8

Answer 3

這不是必要編寫任何測試。 從編寫DAO類的測試中受益？大概。

Answer 4

是的。但很少有人會認爲，它不屬於單元測試的範疇。因爲它不符合單位測試的定義。我們稱之爲集成測試，我們測試代碼與數據庫的集成。

此外，我同意布魯諾的想法在這裏。此外，還有可用的API，一個是DBUnit。

Answer 5

是的。這樣做有幾個好處。一旦你確定你的DAO層工作正常，後期階段的缺陷修復就變得容易了。

Answer 6

我會爭辯說，我們應該爲DAO編寫單元測試，並且最大的挑戰之一就是測試數據的設置和清理。這就是我認爲的框架，比如Spring JDBC測試框架可以讓我們通過使用不同的註釋來控制事務來幫助我們[例子：@Rollback（true）]。例如，如果您正在測試「創建/插入」操作，Spring將允許您在執行測試方法後完成回滾事務，從而始終保持數據庫始終處於其原始狀態。

你可以看看這個鏈接獲取更多信息：Spring Testing

這可能是更加有用，當你的集成測試，你不希望一個測試來破壞數據的完整性，這可能會導致另一測試失敗。

Answer 7

本書的xUnit Test Patterns爲這個問題提供了很多很好的見解。