在 Spring Boot 上下文中使用 h2db 进行集成测试是一种不好的做法吗？

Question

最近，我们的团队提出了一个问题：如果生产环境依赖于不同的数据库引擎（在我们的例子中为 MySQL8），则使用 h2db 进行集成测试是否是一种不好的做法/应该避免。

\n

考虑到我们在后端使用 spring boot/hibernate，我不确定我是否同意这一点。

\n

我做了一些阅读并发现这篇文章https://phauer.com/2017/dont-use-in-memory-databases-tests-h2/基本上说明了以下内容（以及更多内容）：

\n

\n

长话短说

\n

使用内存数据库进行测试会降低测试的可靠性和\n范围。尽管基于 h2 的测试是绿色的，但您的应用程序\xe2\x80\x99s SQL 在生产环境中\n可能会针对真实数据库失败。

\n

\n

\n

它们提供与真实数据库不同的功能。可能的\n后果是：

\n

\n
• 您更改应用程序\xe2\x80\x99s SQL 代码只是为了使\nit 在真实数据库和内存数据库中运行。这可能会导致实施效率较低、优雅、准确或可维护性较差。或者\n你根本无法\xe2\x80\x99 做某些事情。
\n
• 您完全跳过某些\n功能的测试。
\n

\n

\n

据我所知，对于具有一些业务逻辑的简单 CRUD 应用程序，所有这些点都与我有关（本文中还有更多内容），因为 hibernate 包装了所有 SQL 并且代码中没有本机 SQL。

\n

有没有我忽略或没有考虑到的反对 h2db 的观点？关于使用内存数据库与 Spring Boot/Hibernate 进行集成测试是否有“最佳实践”？

\n

Answer 1

如果可能的话我会避免使用 H2 DB。当您无法运行自己的实例时，使用 H2DB 很好，例如，如果您的公司使用 Oracle 之类的东西并且不允许您在任何您想要的地方运行自己的数据库（本地计算机、自己的开发服务器...）。

H2DB的问题如下：

1. H2DB 和您的数据库的迁移脚本可能有所不同。您可能需要对 H2DB 脚本和 MySQL 脚本进行一些调整。

2. H2DB 通常不提供与真正的 RDBMS 相同的功能，您会因仅使用 SQL 而降低数据库的性能，您将无法测试存储过程、触发器和所有可能派上用场的花哨的东西。

3. H2DB和其他RDBMS是不同的。测试不会测试相同的东西，您可能会在生产中遇到一些不会出现在测试中的错误。

说到您的简单 CRUD 应用程序 - 它可能不会永远保持这种状态。

但是，无论你喜欢什么方法，都可以继续，最好亲自获得你的个人经验，我经常被 H2DB 所困扰，不喜欢它。