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