mysql - 在 spring boot 上下文中使用 h2db 进行集成测试是不好的做法吗？

Question

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

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

我做了一些阅读并看到了这篇文章 https://phauer.com/2017/dont-use-in-memory-databases-tests-h2/基本上陈述以下(以及更多):

TL;DR

Using in-memory databases for tests reduce the reliability andscope of your tests. Your application’s SQL may fail in productionagainst the real database, although the h2-based tests are green.

They provide not the same features as the real database. Possibleconsequences are:

• You change the application’s SQL code just to makeit run in both the real and the in-memory database. This may result inless effective, elegant, accurate or maintainable implementations. Oryou can’t do certain things at all.
• You skip the tests for somefeatures completely.

据我所知，对于一个带有一些业务逻辑的简单 CRUD 应用程序，所有这些点都与我无关(文章中还有更多内容)，因为 hibernate 包装了所有的 SQL，并且在代码。

是否有任何我忽略或未考虑的反对 h2db 的观点？是否有关于使用内存数据库与 spring boot/hibernate 进行集成测试的“最佳实践”？

Answer 1

如果可能，我会避免使用 H2 DB。使用 H2DB 很好，当你不能运行自己的实例时，例如，如果你的公司使用像 Oracle 这样的东西，并且不允许你在任何你想要的地方运行你自己的数据库(本地机器，自己的开发服务器......)。

H2DB 的问题如下:

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

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

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

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

但是继续使用您喜欢的任何方法，最好是自己获得个人经验，我经常对 H2DB 感到厌倦，以至于不喜欢它。