我想允许Web服务层（Web服务用Java编写）的消费者创建自动化集成测试，以验证消费者将使用的Web服务层的版本仍然适用于消费者（即Web服务处于与消费者不同的发布生命周期，其API或行为可能会改变 - 它们不应该在没有通知消费者的情况下改变，但是这种自动化测试的目的是验证它们没有改变）如何最好地启用Web服务使用者来集成测试事务性Web服务？
如果Web服务实际执行事务（更新数据库表），我该怎么办？有没有一种常见的做法来处理这个问题，而不必将逻辑放入Web服务本身，以便在单元测试中了解它并在完成后回滚事务？ （基本上可以处理Web服务测试的功能）。或者，这是推荐的方式吗？
消费者是由我们公司的一个开发团队创建的，Web服务是由一个独立团队创建的。该测试将在集成环境中运行（集成环境是由QA功能测试仪，督促环境背后的一个环境中使用的测试环境背后一个环境）
这种事最好的办法是dependency injection。
将数据库处理代码放入一个或多个注入web服务的服务中，并创建在您的测试环境中使用的模拟版本，并且实际上不更新数据库或在其中添加测试中的重置功能控制。
这样，您的测试可以锻炼真正的Web服务，但不是真正的数据库，测试可以更容易地重复。
Java中的依赖注入可以使用（其中）Spring或Guice来完成。 Guice更轻巧一点。
在您注意到基于系统属性的应用程序启动期间作出注入决定时，您可能会明智地决定。
如果某些测试需要将数据库实际更新为有效，那么您的测试版数据库处理将需要使用真实的数据库，但还应提供可从测试中访问的方式，以将数据库重置为已知可能是空的）状态，以便可以重复测试。
我的选择是在生产和托管网络服务层前期制作。您的客户可以进行预生产测试，但不会为其交易收费。
显然，这需要您同时更新生产和预生产。
谢谢 - 请参阅第三段中的其他上下文。 – BestPractices 2012-08-02 13:37:10
也许你可以在WSDL中定义一些版本号并让开发消费者系统的团队检查该版本号？ – mthmulders 2012-08-02 13:50:43
让Web服务运行不变并更新数据库中所需的任何内容。
您的集成测试应检查每个测试步骤后是否已写入/更新了正确的数据库记录。
我们使用soapUI测试平台来完成此操作。
您可以在Groovy和Java中编写测试后断言脚本，这些脚本可以使用JDBC轻松连接到数据库并检查记录。
人们担心使用实际的数据库 - 我不会挂在这上面，这实际上是一件好事，并且为真正准确的测试平台。
关于DB的“状态”，你可以通过多种方式接近这一点：
我们已经采取了后一种方法现在，但如果它变得有问题在未来可能会改变。 我其实不介意用记录填充数据库，因为它使它更像一个真正的客户数据库。在调查测试失败时，它也非常有用。
例如cxf允许您更改传输层。所以你可以改变配置并使用localTransport。那么你可以有对象：客户端和服务器没有任何网络活动。对于测试（联合）marhasling很好。所有其他应该分开，所以业务逻辑不知道web服务，所以它可以作为任何其他类
理想情况下，我不希望修改测试环境和生产（修改注入的内容）之间的部署工件，或使用单独的工具来执行DI。 Spring（除非有一些非常轻巧的东西，我可以轻松部署）。我可以在代码中添加一个检查来检查系统属性，如果我们在测试环境中，那么将创建的Web服务实例将成为测试实例。好/坏主意？如果我真的想要执行db事务呢？ （有些情况下我必须执行它才能成为有效的测试） – BestPractices 2012-08-02 14:22:23