我應該單元測試生成的Java代碼嗎？

Question

簡單的問題。 如果我使用spring-data為我的DAO層生成CRUD方法，我還應該針對生成的方法編寫單元測試嗎？ 或者那相當於單元測試庫代碼？

提前致謝。

編輯：為了澄清，我問的是，除了在發布之前運行的一套集成測試之外，是否還需要編寫單元測試。 例如，DAO層的findAll（）方法的單元測試類似於以下內容：

class DepartmentDAOTest extends spock.lang.Specification {
   /* ... */
   def "returns all departments"() {
       setup:
       def result = new List<Department>()
       when:
       result = dao.findAll()
       then:
       result.size() == EXPECTED_SIZE
   }
}

然而，在標記新版本之前，可能由測試團隊或開發人員手動運行集成測試 。 這可以使用JWebUnit或Geb自動化，並測試每個組件（包括平台），以確保它們在“集成”時按預期工作。

如果我使用JdbcTemplate手動編寫DAO實現，那么毫無疑問我應該對每個方法進行單元測試。 當我對服務層（調用DAO層）進行單元測試時，我可以模擬DAO層，所以我不測試它兩次。

如果我打電話到pdfbox這樣的第三方庫來生成PDF，那么每種方法都有一個期望（因為它是作為pdfbox項目的一部分進行測試的）。 我不測試他們的drawSquare方法確實繪制了正方形，但在集成測試期間，我會看到我的導出PDF功能正確地按照我們想要的方式導出PDF。

所以這個問題應該重新措辭，“我應該在哪個測試階段測試我對彈簧數據的使用？”

Answer 1

不可以。作為一般規則，不要測試平台。

Answer 2

首先，根本沒有生成代碼。 我們根據您聲明的查詢方法構建了一個查詢元模型，並動態執行這些查詢。 這里簡短的回答是：你肯定應該測試這些聲明的方法。 原因很明顯，因為它很簡單：查詢方法聲明 - 無論是使用派生查詢還是手動聲明的 - 都與您為實體定義的映射元數據進行交互。 因此，檢查查詢方法執行以確保您看到預期結果是絕對合理的。 這當然是更多的集成測試和對執行的查詢的語義檢查，而不是經典的單元測試。