如何對QueryDSL Criteria生成進行單元測試？

Question

我將QueryDSL 3.2.4和Spring Data JPA 1.4.2用作我的存儲庫層。 我有一個類來獲取我的Web表單對象（Spring將搜索表單綁定到的一個簡單Bean）並為其生成QueryDSL Criteria對象，然后將該對象傳遞給業務/數據層以運行查詢。

我試圖找出最好的方法來對這一代Criteria對象進行單元測試。 根據要搜索的內容，查詢中將使用不同的字段組合（基本上是典型的搜索表單，其中的字段可以為空，不以此為基礎進行約束，但每個非空白字段均表示搜索條件，有些字段可能還有一些其他選項，例如用於“完全匹配”，“以...開頭”還是“包含”。）

有一個Spring Data JPA教程 ，提倡在JPA Criteria API上使用QueryDSL，部分原因是可以通過比較.toString（）來對QueryDSL進行單元測試。 因此，這就是我現在傾向於的方式，確保所得的Criteria對象的toString（）對於我要測試的查詢而言是合理的，但是我不確定如何獲得“預期” “ toString，而無需提前構造所需的查詢並查看其toString是什么，因此感覺好像不是一個很好的測試，並且感覺它基於QueryDSL的內部結構，該內部結構可能會發生變化。 （我認為大多數類上的toString主要是作為調試工具，而不是規范的一部分，盡管有人指出我關於QueryDSL如何創建其toString（）方法的規范，並且這是使用和/的方式的一部分或測試該庫的使用情況，我想我會更喜歡這種方法。）我希望有更好的方法。

還有另一個StackOverflow問題“ 如何在給定方法內對querydsl查詢進行單元測試？ ”，但這似乎是關於測試整個查詢並需要模擬EntityManager。 我希望只測試Criteria部分，所以我希望有一種比這更簡單的方法，在這種情況下，我需要模擬使用Criteria的Query，然后模擬EntityManager來使用它，並且看起來對我來說，比我要正確創建Criteria對象的單元測試要復雜得多。

我覺得我不可能是唯一要測試我正在創建正確標准的人。 感謝您對我做錯事或如何更好地進行單元測試的任何見解。

Answer 1

我使用真實的EntityManager和真實的內存H2數據庫 “單元”測試所有QueryDSL代碼。 沒有對EntityManager的模擬，也沒有檢查生成的JPQL，我測試查詢是否實際上返回了我期望的對象。

單元測試的純粹主義者可能會認為這不是真正的單元測試，但是我有可以正常工作的代碼，而且它足夠快。

通過springs 嵌入式數據庫支持，這很容易實現：

<jdbc:initialize-database data-source="dataSource">
  <jdbc:script location="classpath:com/foo/sql/db-schema.sql"/>
</jdbc:initialize-database>

Answer 2

我的方法是從簡單的查詢開始，然后收集越來越復雜的“樣本”。 是的，我正在使用實際的查詢結果，並將其復制到單元測試的expected部分中。

這不是一個很好的測試。 目的稍有不同：它記錄了您的期望。

當某些事情發生變化時，您的測試將開始失敗，並且您可以在“我昨天的期望”和“我今天的期望”之間建立區別。

這也記錄了您的代碼的功能。 當發現生產中的錯誤時，您可以嘗試編寫新的單元測試，並查看還有多少其他失敗。 這使您對更改的影響有很好的了解（1個更改+ 90％的測試失敗？您發現了熱點！）

修復錯誤后，我開始看到通常會出問題的模式，並且可以使用特定的單元測試來保護這些位置（例如在大型查詢構建器使用的子構建器中）。

對於一些復雜的查詢，我創建了單元測試以查看它們是否真正起作用。 這使我有信心快速進行“字符串比較”單元測試。