通常，我将从服务/远程层到数据库编写集成测试，以便可以检查服务器端各层是否已集成和测试，如果不这样做，我想将回滚保持为false，否则我们将错过数据库约束级别验证。这是个人喜好。
我们可以采用不同的方法 -为每个测试用例创建数据，并在执行后将其删除 -使用一定数量的现有通用数据（例如（用户））运行
可能有实体依赖于其他几个实体，并且要能够测试这种流程，就需要为每个测试用例或类以及业务流程创建每个实体（如果我们做出决定，我们创建一个实体），则需要付出很多努力。一定数量的数据，并通过一定数量的测试来执行业务流程并清除数据。这些事情会消耗大量时间来运行此类测试用例。
业界是否有有效的方法或最佳实践来在持续集成环境中编写集成测试。我通常使用TestNG，因为它可以提供弹簧支撑。是否有任何基于Java的框架。
答案 0 :(得分：1)
我认为这真的取决于项目，这里没有解决方案。
正如您所陈述的，确实有很多方法，我会列举一些：
在测试中利用Spring的@Transactional注释。在这种情况下，spring将在每次测试后执行回滚。因此即使测试通过，测试更改的数据也不会真正保存在数据库中。
请勿使用@Transactional，而是组织测试，以免干扰（每个测试将使用其自己的数据集，该数据集可与其他测试数据共存）。如果测试失败并且没有“清理”其内容，则其他测试仍应运行。此外，如果测试是并行运行的，它们仍然不应干扰。
为每个测试使用新的架构（显然很昂贵，但对于某些项目仍然可以选择）。
现在，真正的问题是您要测试什么。 如果您测试Java代码（例如正确创建SQL），那么第一种方法可能是可行的方法。
当然，这还取决于测试期间正在执行哪些命令，并非所有数据库中的所有命令都可以在事务中进行（例如，在Postgres中可以在事务内部使用DDL，而在Oracle中则不能，依此类推）。
在连续测试中要考虑的另一个问题是测试的性能。 集成测试很慢，如果您有一个运行数百个的整体应用程序，那么构建将真的很慢。管理运行数小时的构建是一个很大的痛苦。 我想在这里提一下2个可以在这里有所帮助的想法：
在这种情况下，迁移到微服务有很大帮助（每个微服务仅运行其一系列测试，因此本质上每个微服务的构建速度要快得多）
要考虑的另一个有趣选项是针对在测试用例中启动的数据库的docker容器运行测试（它也可以缓存，因此并非每个测试都会引发docker容器）。这种方法的一大好处是，所有操作都在本地运行（在构建服务器上），因此即使某些测试失败，也不会自动与远程数据库进行交互（性能）+资源清理。 Docker容器死亡，tets放置的所有数据将自动清除。看看Testcontainers项目，也许会对您有所帮助