我一直在尋找EasyMock和單元測試DAO類，用於「外部容器」測試的教程/示例。不過，我認爲他們中的大多數都會談論測試服務層，而不是模擬DAO類。我有點困惑，它是真的如何單元測試DAO層？DAO單元測試
有人會說，與DB &交互測試的EJB實際上是集成測試，而不是單元測試，但那麼你怎麼知道，如果你的SQL是正確的（假設沒有ORM），並從你的DAO插入/查詢正確的數據真正的（讀取，與生產中的數據庫類似的本地數據庫）數據庫？
我讀到DBUnit是解決這種情況的解決方案。但我的問題是關於使用DBUnit「外部容器」之類的框架。如果DAO依賴於某些EJB，那麼如何處理這些事務？如果觸發器更新插入中的其他表，會發生什麼情況？
什麼是單元測試的最佳方式只測試具有這種依賴性的DAO？
就我個人而言，我通過點擊某種測試數據庫來測試DAO，最好是您的應用程序在生產中使用的相同類型的數據庫（顯然不是相同數據庫）。
我想如果你這樣做，測試更多的是一個集成測試，因爲它依賴於運行的數據庫。這種方法的好處在於它儘可能接近正在運行的生產環境。它的缺點是你需要測試配置，你需要一個正在運行的測試數據庫（本地到你的機器或你的環境中的某個地方），測試可能需要更長時間才能運行。您還需要確保在執行測試後回滾測試數據。
一旦DAOs被測試，絕對嘲笑他們單元測試您的服務。
我正在使用HSQLDB進行Dao和Service API測試。性能很好，它也支持交易。我沒有使用EJB。我使用Hibernate。
有一些問題，我知道在不同的數據庫上運行測試可能會掩蓋一些受支持的數據庫問題。但我認爲這樣的問題應該在煙霧&驗收測試中被捕獲。
問候， 高野
通常用的DAO的想法是讓周圍的數據訪問代碼的最小包裝，所以什麼都沒有，除了映射到數據庫進行測試，並與嘲笑單元測試是沒用的。如果實際上DAO中有邏輯值得使用mock進行測試，那麼可能會說您濫用DAO模式並且邏輯應該處於服務中。
用於測試映射到數據庫DBUnit是有用的，因爲它允許您在測試之前指定起始數據集，以便您的測試從已知狀態開始，並且它允許您指定數據的結束狀態應該是什麼，所以你不必編寫大量的單元測試代碼來斷言什麼是預期的。
理想情況下，如果您有像Hibernate這樣的工具將數據庫抽象出來，您可以使用像H2或HSQLDB這樣的內存數據庫，這樣您的測試運行得更快，並且不需要創建數據庫。如果您必須使用真實的數據庫，請確保您的測試具有自己的測試，以便他們可以創建和刪除數據，而不會影響其他進程或受其他進程的影響。在實踐中，本地和CI環境中都有一個數據庫不太可能，並且使用內存數據庫更加實用。
我最終定居編寫，可以在容器外運行單元測試，用一個活生生的數據庫和事務支持使用一個獨立的事務管理器（Bitronix），我能夠也回滾。我想這不會使測試純單元測試仍然... ...很想聽到你的意見人士在這種方法。
上的補充高野anwers，您可以使用HSQLDB進行DAO測試。我想你在你的項目中使用了Spring和Hibernate。您需要單獨的配置文件指向HSQLDB，您需要在執行測試之前插入數據。對於使用HSQLDB可以做什麼有一些限制，但一般用作查詢和連接是可以的。有了這個解決方案可以在連續的環境中使用，例如jenkins。 集成測試可以使用HSQLDB，所以這部分不會被模擬。