測試方法 - 數據庫，Junit

我想問你有關與數據庫中的數據相關的寫入測試。在我看來，最好的方法是使用不同的數據庫模式，僅在單元測試時使用正確的數據。在測試代碼中，我可以在ID的基礎上加載對象。測試方法 - 數據庫，Junit

第二一種可能是在單元測試過程中將數據放入數據庫。我不喜歡它。

你怎麼想。你怎麼做到這一點？

親切的問候塞巴斯蒂安

來源

2010-02-09 Sebastian

如果你真的想編寫與數據庫交互的測試 - 集成測試 - 那麼你必須把你的數據庫中已知的狀態每次測試執行之前。要做到這一點

一種方法是使用DbUnit每次測試之前加載自定義數據集，例如。在這裏，每個測試都負責他自己的數據，不需要清理，並且可以在測試失敗後查詢數據庫以瞭解問題。

另一種方法是使用一個「活」的數據庫，並運行一個事務內部測試，並回滾在測試結束的變化。 Spring和Unitils對此有支持。這很有效，但使用這種方法診斷失敗的測試並不總是很容易。

需要注意的是第二種方法並沒有真正排除第一個，你可以使用自定義的數據集在事務內。另外請注意，您可以使用包含「參考數據」（即只讀數據，如國家等）的數據庫，並且只使用「動態數據」來加快使用第一種方法時的速度。

就個人而言，我並不真正看到前一種方法有什麼問題（除了可能測試速度稍慢），像DbUnit這樣的工具使它變得非常容易。正如我所說的，我發現使用DbUnit進行測試更容易診斷。但後面的方法肯定也起作用。

在這兩種情況下，你當然應該使用專用模式。

_{實際上，每個開發人員使用一個模式肯定是best practice。}

來源

2010-02-09 15:43:18

太棒了！非常感謝你。 – Sebastian 2010-02-10 06:44:28

帕斯卡爾，很好的詳細答案。你在那裏提到它，但我認爲強調與活動數據庫交互的測試通常是集成測試是很重要的。使用一個實時數據庫進行單元測試會是過分的，嘲笑它是合適的。 – 2010-02-10 13:06:50

單元測試，你應該嘲笑或存根數據庫的功能。由於您正在測試調用數據庫的對象而不是數據庫本身，因此不需要使用真實的數據庫。 EasyMock或JMock是很好的嘲諷庫來研究。

來源

2010-02-09 13:53:13

謝謝。如果我有一個大對象圖怎麼辦？然後，我需要編寫大量代碼來模擬對其他對象的每個引用。 Im在服務層使用模擬來模擬DAO層，因爲DAO層已經過測試。而且，我還在GUI層中使用模擬來模擬服務層，因爲服務層已經過測試。你不覺得模擬數據庫來測試DAO層不是一個好主意嗎？我們想測試它，但在這種情況下，我們將測試模擬對象。你怎麼看？謝謝你的回答。 – Sebastian 2010-02-09 13:58:45

如果模擬的對象太多，這可能意味着你的設計太複雜了，而一個課也許有太多的責任。沒有看到實際的代碼，很難說，但看看你能否簡化一下。至於數據庫，如果您正在模擬數據庫，那麼如果您的測試是針對DAO的，則不會測試模擬對象。您正在測試DAO將正確的命令發送到數據庫。對於DAO測試，假設數據庫將按預期運行是安全的（並且您可以隨時嘲笑它以執行意想不到的事情來測試錯誤情況）。 – 2010-02-09 14:10:59

非常感謝。 – Sebastian 2010-02-09 14:29:55

三種意見：

單元測試通常是小規模，快速的測試，以覆蓋小片的代碼。使用數據庫進行測試並不是真正的單元測試（即使您可以在例如JUnit中運行它們），而是進行系統/集成測試。兩者對於不同的目的都很有用。
即使你的對象圖是很大的，我不明白爲什麼你需要在單元測試一次測試這一切。您使用必要的模擬對象測試一個DAO，並斷言對象圖的相關部分處理正確。然後編寫更多的測試下一個DAO等
IMO的DAO通常不應該做非常複雜的事情（除非業務邏輯的一部分被擺在那裏，但是這是很糟糕的設計 - 需要重構，而不是試圖掩蓋它與扭曲的單元測試）。

來源

2010-02-09 14:17:54

非常感謝。 – Sebastian 2010-02-09 14:29:30

測試方法 - 數據庫，Junit

回答

相關問題