Disgusting web service response | Link a couple of them in a web application

Question

I work in a corporate project, and my team is responsible for creating the external interface of the application, and there is another team that develops web services and provides WSDL for all services that will be available as part of this project. At the development stage, our local dev environment will point to one of the development areas of the team responsible for creating web services. It is possible that the environment of their developers will be shaky in the middle of the iteration. To mitigate this risk, we use the SOAP interface on our local machine and begin to mock the service and do development. Whenever we need different tastes of a response, we modify the XML response request to the local service. This process works well, but I was wondering if there is a way that for each service says that I create 10 answers and deploy them as a war with tomcat on one of the machines, and my entire development team points to the war that will expose the same service, and based on the parameter, it can send one answer out of 10 answers included in the war. I do not want to spend any effort on this. Is there a tool that provides such functionality out of the box.

Answer 1

It will simplify your life if you dissect your internal architecture a bit. Instead of allowing the client code to rely on an external SOAP service in an inflexible manner, it would be useful to define an interface for internal use. You can call it IServiceProxy or some such name.

Let the client code talk to this interface and use Injection Dependency (DI) to insert an instance of it into the client. This means that for a lot of development use, you can simply replace this interface with a test one (for example, Mock).

If you also need to have a SOAP service to make sure your SOAP stack is working as intended, pay attention to the so-called Shared Fixture test smell. The joint “test” service on the same server will be Shared Fixture, and this is likely to give you more problems than it costs, because the developers will step over each other and this will be a bottleneck.

The best alternative is to configure the SOAP service on each developer machine or, if this is not possible, a dedicated service for each developer.

You can learn more about Shared Fixtures and many other test patterns and anti patterns in the excellent xUnit Test Patterns .

Answer 2

I was in the same situation when the testing group wanted to test another scenario, which required from time to time to mock the changed service. Since most of the personal testing team was non-technical, I always needed to update the soapUI mockup. To avoid this, I created a completely web-based application to mock the service using WSDL. Since these are fully web testers, they were able to modify the mocked service from their web browsers.

The application is written on top of the soapUI framework. It provides features such as automatically generating a SOAP message and verification confirmation, etc. The utility also allows you to mock the service with a delay, which helps with performance testing.

Now I have added the application to SourceForge. See link below

http://sourceforge.net/projects/easymocker/

(Web Service Mocker is an easy-to-use utility for SOAP web services based on web services. This utility is very useful in the SOA development environment during unit test, component integration test and non-functional requirements testing.)

Answer 3

I encountered a similar problem earlier

We created a mock host web service application using WSDL that requires a service layout

All different answers are saved in different XML files on the server

In the web service code, we simply put the key with a unique identifier in the web service request and inside the switch block, we send a response from a specific XML file stored on the server corresponding to the unique identifier

This was possible because the response was mostly static and will vary depending on the only unique identifier in the request

It took a little time to create and deploy, as we had convenient answers

We hope this helps you based on the context of your application.