我想允许 Web 服务层的消费者（Web 服务是用 Java 编写的）创建自动化集成测试，以验证消费者将使用的 Web 服务层版本是否仍然适用于消费者（即 Web 服务是在与消费者不同的发布生命周期中，他们的 API 或行为可能会改变——他们不应该在不通知消费者的情况下改变，但这个自动化测试的重点是验证他们没有改变）
如果 Web 服务实际执行事务（更新数据库表），我会怎么做。是否有一种常见的做法来处理这个问题，而不必将逻辑放入 Web 服务本身以在单元测试中知道它并在完成后回滚事务？（基本上是在处理 Web 服务测试的能力）。或者这是推荐的方法？
消费者由我们公司的一个开发团队创建，Web 服务由一个单独的团队创建。测试将在集成环境中运行（集成环境是 QA 功能测试人员使用的测试环境后面的一种环境，prod 环境后面的一种环境）
处理这类事情的最佳方法是依赖注入。
将您的数据库处理代码放入一个或多个注入到 Web 服务中的服务中，并创建在您的测试环境中使用的模拟版本，并且不会实际更新数据库，或者您在测试控制下添加重置功能。
这样，您的测试可以运行真正的 Web 服务而不是真正的数据库，并且可以更轻松地使测试具有可重复性。
Java 中的依赖注入可以使用（除其他外）Spring或Guice来完成。Guice 更轻量级。
在您的情况下，根据您注意到的系统属性在应用程序启动期间做出注入决策可能是明智的。
如果某些测试需要实际更新数据库以使其有效，那么您的数据库处理测试版本将需要使用真实数据库，但还应提供一种可从测试访问的方法，以将数据库重置为已知（可能为空）状态以便可以重复测试。
我的选择是在生产和预生产中托管 Web 服务层。您的客户可以针对预生产进行测试，但不会为他们的交易付费。
显然，这需要您同时更新生产和预生产。
让 Web 服务保持不变并更新数据库中所需的任何内容。
您的集成测试应在每个测试步骤后检查是否写入/更新了正确的数据库记录。
我们使用一个soapUI 测试平台来完成这个。
您可以使用 Groovy 和 Java 编写测试后断言脚本，这些脚本可以轻松地使用 JDBC 连接到数据库并检查记录。
人们担心使用实际的数据库——我不会挂断这件事，这实际上是一件好事，并且可以提供一个非常准确的测试平台。
关于数据库的“状态”，您可以通过多种方式解决此问题：
我们目前采用了最后一种方法，但如果出现问题，将来可能会改变。我实际上不介意用记录填充数据库，因为它使它更像一个真正的客户数据库。在调查测试失败时它也非常有用。
例如 cxf 允许您更改传输层。因此您只需更改配置并使用 localTransport。那么你可以拥有对象：没有任何网络活动的客户端和服务器。它非常适合测试（un）marhasling。其他所有内容都应该分开，因此业务逻辑不知道 Web 服务，因此可以像任何其他类一样对其进行测试