一般来说，我从服务/远程处理层向数据库编写集成测试，以便我可以检查服务器端层是否已集成和测试，我希望将回滚保持为 false，否则我们将错过数据库约束级别验证。这是个人喜好。
我们可以采用不同的方法 - 为每个测试用例创建数据并在执行后删除它 - 使用一定量的现有公共(public)数据(例如(用户))运行
可能有一些实体依赖于其他几个实体，并且为了能够测试此类流程，需要付出很大的努力来为每个测试用例或类创建每个实体，并且如果我们做出决定，我们可能会创建一个业务流程一定量的数据，执行一定数量的业务流程，测试并清除数据。这些事情可能会消耗大量时间来运行此类测试用例。
业界是否有遵循的有效方法或最佳实践来在持续集成环境中编写集成测试。我通常使用 TestNG，因为它提供 Spring 支持。有没有基于Java的框架。
最佳答案
我认为这实际上取决于项目，并且这里没有银弹解决方案。
正如您所说，确实有很多方法，我只提一些:
在测试中利用 Spring 的
@Transactional注释。在这种情况下，spring会在每次测试后执行回滚。这样即使测试通过了，测试改变的数据也不会真正保存到数据库中。不要使用@Transactional，但组织测试，使其不会干扰(每个测试将使用自己的一组数据，这些数据可以与其他测试数据共存)。如果测试失败并且没有“清理”其内容，那么其他测试仍然应该运行。此外，如果测试并行运行，它们仍然不应该干扰。
为每个测试使用新的架构(显然很昂贵，但对于某些项目来说仍然是一个可行的选择)。
现在，真正的问题是您要测试什么。 如果您测试 java 代码，例如您的 SQL 已正确创建，那么第一种方法可能是一种方法。
当然，这也取决于测试期间执行的命令，并非在所有数据库中所有命令都可以在事务中(例如在 Postgres 中您可以在事务中使用 DDL，在 Oracle 中则不能) ，等等)。
在连续测试过程中要考虑的另一个问题是测试的性能。 集成测试很慢，如果您有一个运行数百个集成测试的整体应用程序，那么构建将会非常慢。管理运行数小时的构建是一个很大的痛苦。 我想在这里提到两个可以提供帮助的想法:
在这种情况下，迁移到微服务有很大帮助(每个微服务只运行一堆测试，因此每个微服务本身的构建本质上要快得多)
另一个值得考虑的有趣选项是针对在测试用例中启动的数据库的 docker 容器运行测试(它也可以被缓存，这样不是每个测试都会引发 docker 容器)。这种方法的一大好处是，所有内容都在本地运行(在构建服务器上)，因此即使某些测试失败，也不会与远程数据库(性能)交互+自动完成资源清理。 Docker 容器死亡，tets 放入的所有数据都会自动清除。看看Testcontainers项目也许你会发现它很有帮助
关于java - 编写在持续集成环境中运行的集成测试的最佳实践或有效方法，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/53137869/