我对WireMock完全不熟悉.

到目前为止,我一直在使用SOAPUI进行模拟响应.我的用例很简单：

只是将SOAP XML请求发送到不同的端点(http://localhost:9001/endpoint1)并获取固定的XML响应.但是MockWrire必须作为独立服务部署到专用服务器上,该服务器将作为模拟响应的中心位置.

只想要一些开始的建议.我可以看到WireMock更适合REST Web服务.所以我的怀疑是：

1)我是否需要将其部署到Java Web服务器或容器以充当始终运行的独立服务.我读到你可以通过使用来剥离

java -jar mockwire.jar --port [port_number]

2)我是否需要使用MockWire API？我需要为我的用例制作课程吗？在我的例子中,请求将通过JUnit测试用例触发以进行模拟.

3)如何实现简单的URL模式匹配？如上所述,我只需要简单的模拟,即在请求http://localhost:9001/endpoint1时获得响应

4)我的用例是否有更好/更容易的框架？我读到了Mockable,但它对3个团队成员和免费层的演示域有限制.

解决方法:

我是WireMock的创造者.

我最近使用WireMock在客户端项目上模拟了SOAP接口的集合,所以我可以证明它是可能的.至于它是否比SOAP UI更好或更差,我会说有一些明确的好处,但有一些权衡.一个主要的好处是相对容易部署和编程访问/配置,以及对HTTPS和低级故障注入等方面的支持.但是,您需要做更多的工作来解析和生成SOAP有效负载 – 它不会像SOAP UI那样从WSDL生成代码/存根.

我的经验是像SOAP UI这样的工具可以让你更快地开始,但是从长远来看,当你的测试套件变得越来越琐碎时,往往会导致更高的维护成本.

要依次解决您的观点：
1)如果您希望您的模拟在某个服务器上运行,最简单的方法是按照您的描述运行独立的JAR.我建议不要尝试将它部署到容器中 – 这个选项实际上只存在于没有其他选择的情况下.

但是,如果您只想运行集成测试或完全自包含的功能测试,我建议使用JUnit规则.我要说,如果a)你将其他已部署的系统插入其中,或者b)你是从非JVM语言中使用它,那么在一个专用的进程中运行它是一个好主意.

2)您需要以3种方式之一配置它：1)Java API,2)基于HTTP的JSON,或3)JSON文件. 3)可能与您习惯使用SOAP UI的方式最接近.

3)对于使用JSON和Java的大量存根示例,请参见http://wiremock.org/stubbing.html.由于SOAP倾向于绑定到固定端点URL,因此您可能需要urlEqualTo(…).当我过去使用SOAP时,我倾向于在整个请求体上进行XML匹配(参见http://wiremock.org/stubbing.html#xml-body-matching).我建议投资编写一些Java构建器来发出所需的请求和响应主体XML.

4)Mock Server和Betamax都是WireMock的成熟替代品,但AFAIK它们不提供任何更明确的SOAP支持.