是否应该直接测试 Spring Boot 应用程序中的存储库？答案

【问题标题】：Should repositories in Spring Boot applications be tested directly?是否应该直接测试 Spring Boot 应用程序中的存储库？
【发布时间】：2019-02-26 16:15:43
【问题描述】：

不确定这是否会被视为“合法问题”或“纯粹基于意见”，但在 Spring Boot 应用程序中直接测试存储库是否有“最佳实践”？或者，任何集成测试都应该只针对相关服务吗？

这个问题的原因很简单，在大多数情况下，Spring Boot 应用程序中的存储库不包含项目生成的代码。充其量，它包含 Spring 为其生成实现的项目定义的方法签名（假设正确的命名约定）。

谢谢...

【问题讨论】：

Repository 是一个刻板印象。是作为组件或服务注释类的弹簧组件。你是指 JpaRepository 还是 CrudRepository？
您为什么要测试存储库，因为您没有自己编写代码？我假设你继承自 JpaRepository 或 CrudRepository。
继承自 CrudRepository 接口。 “没有编写代码”（除了声明新的方法签名）是我质疑针对存储库编写任何 JUnit 测试的价值/需要的原因。似乎这可以推迟到使用存储库的服务实现的集成测试。但是，由于我是 Spring 新手，所以我想获得意见。

标签： spring spring-boot integration-testing spring-repositories

【解决方案1】：

如果你能把它搞砸，你应该测试它。在这里搞砸的机会可能包括：

自定义查询（使用 @Query）可能是错误的（可能存在各种逻辑错误或拼写错误，编写查询时未进行编译时检查）
从方法名称派生查询的存储库方法可能不是您想要的。
传入的参数，参数列表中的类型可能与查询中所需的类型不匹配（编译时没有强制执行此操作）。

在所有这些情况下，您不是在测试 Spring Data JPA，而是在测试使用 Spring Data JPA 实现的功能。

使用提供的方法开箱即用的案例，例如 findOne、findAll、save 等，如果您的指纹不在上面，则不需要测试。

测试这些东西很容易，而且最好早点发现错误。

【讨论】：

好的，这对我来说很有意义......测试，但仅限于在本地项目级别的存储库接口中声明的那些东西。我可能会补充一点，即使在开箱即用的 Spring Data JPA 方法上（例如，添加/更新时的约束错误等），包含对预期错误条件的测试似乎也是谨慎的做法。格拉齐...

【解决方案2】：

是的，我认为这样做是一个很好的做法。您可以使用 @DataJpaTest 注释，它启动内存数据库。官方文档说：

You can use the @DataJpaTest annotation to test JPA applications. By default, it configures an in-memory embedded database, scans for @Entity classes, and configures Spring Data JPA repositories. Regular @Component beans are not loaded into the ApplicationContext.

文档链接：https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-testing.html

【讨论】：

我了解“如何”测试存储库。我的问题是“为什么这是一个好习惯？”

【解决方案3】：

从存储库应该只在服务内部使用并且服务用于与系统的其他层交互的想法开始，我想说在大多数情况下测试服务就足够了。

我不会测试像 findAll 或 findBy.. 这样的标准存储库方法，它们已经过测试，目的不是测试 JPA，而是测试应用程序。

唯一应该进行直接测试的存储库方法是具有自定义查询的方法。这些查询可能位于共享库中，跨不同项目编写类似测试效率不高（在这种情况下，回归是一个大问题）

【讨论】：