为数据访问代码编写测试

为数据访问代码编写测试–不测试框架

当我们向数据访问代码编写测试时，是否应该测试其公共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接口声明的方法编写测试，则必须对所有存储库编写这些测试。如果选择这种方式，我们将花费大量时间为其他人的代码编写测试，坦率地说，这样做是不值得的。
我们自己的代码可能是如此简单，以至于将测试写入我们的存储库是没有意义的。

换句话说，我们应该集中精力寻找这个问题的答案：