當我們向數據訪問代碼編寫測試時，是否應該測試其公共API的每種方法？

一開始聽起來很自然。 畢竟，如果我們不對所有內容進行測試，那么如何知道我們的代碼可以按預期工作呢？

這個問題為我們提供了重要的線索：

我們的代碼 。

我們應該只對自己的代碼編寫測試。

什么是我們自己的代碼？

有時很難確定我們應該測試的代碼。 原因是我們的數據訪問代碼與將信息保存到使用的數據存儲中或從中讀取信息時所使用的庫或框架緊密集成在一起。

例如，如果我們要創建一個向Todo對象提供CRUD操作的Spring Data JPA存儲庫，則應創建一個擴展CrudRepository接口的接口。 TodoRepository接口的源代碼如下所示：

import org.springframework.data.repository.CrudRepository;public TodoRepository extends CrudRepository<Todo, Long> {}

即使我們沒有向存儲庫接口添加任何方法， CrudRepository接口也聲明了許多可供使用我們存儲庫接口的類使用的方法。

這些方法不是我們的代碼，因為它們是由Spring Data團隊實現和維護的。 我們只使用它們。

另一方面，如果我們向存儲庫添加自定義查詢方法，情況將發生變化。 假設我們必須找到標題等于給定搜索詞的所有待辦事項。 在將此查詢方法添加到存儲庫接口后，其源代碼如下所示：

import org.springframework.data.repository.CrudRepository; import org.springframework.data.repository.query.Param;public TodoRepository extends CrudRepository<Todo, Long> {@Query("SELECT t FROM Todo t where t.title=:searchTerm")public List<Todo> search(@Param("searchTerm") String searchTerm) }

可以很容易地斷言該方法是我們自己的代碼，這就是為什么我們應該對其進行測試。 但是，事實有點復雜。 即使JPQL查詢是由我們編寫的，Spring Data JPA仍會提供將查詢轉發給使用過的JPA提供程序的代碼。

而且，我仍然認為該查詢方法是我們自己的代碼，因為其中最重要的部分是由我們編寫的。

如果要標識自己的數據訪問代碼，則必須找到每種方法的基本部分。 如果這部分是我們編寫的，則應將該方法視為自己的代碼。

這一切都是顯而易見的，更有趣的問題是：

我們應該測試嗎？

我們的存儲庫接口為使用它的類提供了兩種方法：

它提供了由CrudRepository接口聲明的方法。

它提供了我們編寫的查詢方法。

我們是否應該將集成測試寫到TodoRepository接口并測試所有這些方法？

不，我們不應該這樣做，因為

CrudRepository接口聲明的方法不是我們自己的代碼。 這段代碼是由Spring Data團隊編寫和維護的，他們已經確保它可以工作。 如果我們不相信他們的代碼有效，則不應使用它。

我們的應用程序可能有許多存儲庫接口，這些接口擴展了CrudRepository接口。 如果決定對CrudRepository接口聲明的方法編寫測試，則必須對所有存儲庫編寫這些測試。 如果選擇這種方式，我們將花費大量時間為其他人的代碼編寫測試，坦率地說，這樣做是不值得的。

我們自己的代碼可能是如此簡單，以至于將測試寫入我們的存儲庫是沒有意義的。

換句話說，我們應該集中精力尋找這個問題的答案：

我們應該將集成測試寫入我們的存儲庫方法（由我們編寫的方法），還是只編寫端到端測試？

這個問題的答案取決于我們存儲庫方法的復雜性。 我知道復雜性是一個模糊的詞，這就是為什么我們需要某種準則來幫助我們找到測試存儲庫方法的最佳方法的原因。

做出此決定的一種方法是考慮測試每種可能情況所需的工作量。 這是有道理的，因為：

將集成測試寫入單個存儲庫方法比將相同的測試寫入使用存儲庫方法的功能所需的工作更少。

無論如何，我們都必須端對端地編寫。

這就是為什么最小化我們的投資（時間）和最大化我們的利潤（測試覆蓋率）的原因。 我們可以按照以下規則進行操作：

• 如果我們只編寫幾個測試就可以測試所有可能的場景，那么我們就不應該浪費時間將集成測試寫入我們的存儲庫方法。 我們應該編寫端到端測試，以確保該功能按預期工作。
• 如果我們需要編寫多個測試，則應將集成測試寫入存儲庫方法，而僅編寫一些端到端測試（煙霧測試）。

摘要

這篇博客文章教會了我們兩件事：

• 我們不應該浪費時間將測試編寫到其他人編寫的數據訪問框架（或庫）中。 如果我們不信任該框架（或庫），則不應使用它。
• 有時我們也不應該對數據訪問代碼編寫集成測試。 如果經過測試的代碼足夠簡單（我們可以通過編寫一些測試來涵蓋所有情況），則應該通過編寫端到端測試來對其進行測試。

翻譯自: https://www.javacodegeeks.com/2014/07/writing-tests-for-data-access-code-dont-test-the-framework.html

總結

以上是生活随笔為你收集整理的为数据访问代码编写测试–不测试框架的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。