想知道是否有可能完全擺脫SQL依賴。假設我正在編寫與DB進行通信的測試，這就需要管理數據庫模式，這是非常麻煩的，因爲內存數據庫通常與生產類型數據庫不匹配。休眠/ JPA無DB
是否可以使用Hibernate/JPA進行測試，並且沒有下劃線DB模式？
我知道目前有兩種選擇，我想在這裏擴大我的知識，如果有任何其他可能性，請分享。
或者我應該只專注於模擬DAO層，而不是與此浪費時間呢？ Sanity檢查JPA實體與DB是完全不同的故事。
您擔心內存數據庫和生產數據庫之間的差異嗎？但是你不害怕你的兩個「模擬」選項和生產之間的差異大得多嗎？
從我的角度來看，任何更換生產數據庫進行測試都會以某種方式產生誤報。我猜想一個內存數據庫最能模仿真實的環境。特別是如果你使用類似H2這種嘗試支持不同SQL方言的東西。
只要你只寫小封裝的單元測試，你的DAO層的模擬也會有所幫助。但是，只要您正在編寫集成測試，您就需要以某種方式提供數據庫。
而且沒有 - 沒有數據庫模式或連接，Hibernate不能工作。
這個問題更多的是單元測試，無論如何，現在我正在研究更接近集成測試。你對模擬和數據庫之間的巨大差異是正確的。在發佈代碼之前，集成測試應該是最後一個自動化點。我現在的擔憂是嵌入式數據庫的可靠程度如何（模擬生產數據庫）。肯定總是存在一些風險（更不用說某些情況根本無法模仿）。我們應該對生產有多接近？對於我來說，我們能夠以最自然的方式使用容器（Docker）和真實數據庫 – Zveratko
即使您完全模仿生產數據庫 - 您也需要編寫測試來檢測特定於生產的錯誤_stable_ - 沒有人喜歡一次又一次地改變測試，只是因爲生產中的數據發生了變化。甚至那些測試也不會發現所有的錯誤。我認爲你最終會得到與一個（某種程度上穩定的）內存數據庫一起工作的集成測試。這就是我在我的許多項目中所擁有的。 –
只是出於好奇，你如何正在做集成測試。設置環境，檢查斷言等。 – Zveratko
這沒有任何意義。測試應該顯示問題，你喜歡嘲笑有問題的東西來忽略它們？ –
但是，如果你正在進行精確的單元測試，重點關注其他一些失敗點。我的意思是你沒有測試你需要測試某些功能的數據庫，並且你需要有一些簡單的方法來切斷對數據庫的依賴。在這種情況下，您需要按照您希望它在正常情況下工作的方式來模擬數據庫行爲。 – Zveratko
切斷DB是正常情況？爲什麼要測試代碼和模擬一些，如果你可以在集成測試中測試所有的*常規conditin *？ –