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