Mocking web services for testing and fault injection

WebService Test Strategy

Web services are generally the core pillars of any software development in today’s information technology world. More and more companies are modeling their offerings based on service oriented architecture (SOA). The application logic becomes more relevant to presentation only, leaving the heavy lifting of logic to be done via web services. Further there are different types of services including SOA, REST etc. which makes the mix a little more interesting.

While services becoming increasingly important, it’s also making the app level testing a little bit more interesting. An app should be tested not only for the functionality but also for being able to handle different types of issues related to consumption of services. Testing app layer for functionality, performance, graceful degradation and disaster recovery are some of the very important aspects and need an intelligent solution around service mocking.

There are many ways the web service mock testing can be done. For example some team may use a request and whatever response is received, it can be saved along with code for further consumption for testing. Or the response can be saved in the form of xml serialized file. Further ways include using aspect based programming where the calls to actual service is routed to mock api which can construct the mock response and send it to the caller.

Here I will discuss a model that can help us achieve the following from test standpoint:

Provide mocking capability when actual service call is either not necessary or not available
Handle the service request calls intelligently for either mocking or rerouting to actual service calls
Inject the time delays in serving service responses based on requests
Inject timeouts, exceptions and error scenarios for service requests (meaning providing error for responses like error code 404/504 etc)
Scale with the usage of the test system across the board
In synch with most of the service layer changes
Be able to work as an abstraction layer for mock as well as actual service calls for more stability

Service test model

Lets assume that a new web service is being constructed. This proposal has three key components:

Mock service clients

Each service should provide a mock service client in addition to the actual service client. The actual service client will have http end point to the real service, say ‘S1 Service’. The mock service client, say ‘S1 Mock ServiceClient’, will have http end point to a component called ‘Test Server’. The mock end point will have few query parameters added to the request to denote which web-service it is intended to talk to and if the request should be served from mock/stored response repository or rerouted to original web-service.

Test Server

Test server is single entry point to cater to all service end points for mocking, testing and stabilizing purpose. It will be a test service which will be behind a load balancer to facilitate the scalability as and when needed. The test server serves two purposes. Based on the request type, it can either serve the response from its cache or reroute the call to actual service implementation. Mostly the implementation of test server will be a mix of custom code logic combined with rerouting software. Apache camel is a great example of rerouting part. The job of test server are three folds:

Validate the service request : The test server is designed to test application code while mocking/stability from web services. Hence this should always be used internally for any company and should not become end customer facing. In order to server internal traffic, every request made to this server should be validated. It can be checked for internal IP range, authenticity of the originating host. It can also be done via application level authentication tokens.
Service identification : This part analyzes the service request. This component is responsible to populate the required data model for test server with parameters of the web service request. The information includes the choice of service originator for a mock/cached response or routing to actual service implementation. It can also find if the originator needs any type of time delay in service response to test how efficiently application code handles the latencies and service outages. It can also inject different types of fault conditions while serving responses.
Serve Response : This component is responsible to provide the appropriate response based on the request. Serve response module gathers the information from test server data model for the request and then decides to either reroute the service call to original service or serve the response from its cache/storage.

Points to note about test server is that it can be used to test multiple type of scenarios. That includes mocking responses, introducing time delays in responses etc.

Response delivery

Responses to the web service calls are delivered via this system. Its responsibilities include analyzing the data model sent by test server and provide responses either by fetching cached/stored response for exact request matches or re-routing service requests to respective actual service end points. There are two main components for this system:

Cached Response : This module takes care of providing the response back to ‘serve response’ module from its cache. Based on the service endpoint and request parameters, it does following steps:
If it finds an exact match for the request in its cache/‘service response storage’, it fetches that response and send it back to the Serve Response module
If it does not find an exact match for the request, it makes a service call to actual service, stores the request parameters and response in cache/storage and send it back to serve response module
Periodically (configurable time interval like every midnight), it invalidates the cached/stored responses. It makes actual service calls and replaces the cached/stored responses with the latest received responses
If there is any problem while fetching the service response from actual service end point, it logs it and also sends the notifications
Service Response Storage (SRS): SRS is a storage or cache implementation for mocking actual service calls. It can be achieved by creating data model based on per service end points it mocks. Then further, every service endpoint based data model can store the responses based on service requests. All the service request parameters need to be stored in order to ensure that the exact matched request and responses. It needs to be fast as it should become bottleneck in serving responses. It should have very less latency.

Summery

I believe the testing model of mocking the web services should be based on real service calls itself. It should be able to provide most of the behaviors that can be expected (and unexpected one’s as well!) from an actual service call. Keeping that in mind, I have tried coming up with this model. It serves the purpose of being able to mock the service calls by replacing them with in memory/cached/stored responses. It can also be used to inject fault conditions in response to the service calls and hence enabling us to test the app logic behavior in such cases. Finally it can also be used to completely replace the actual service calls, if needed and if latency is not an issue in testing domain, to achieve the service stabilities.

Please do let me know your comments and hopefully we can create a better model along the lines. And yes, in the process, will make our lives little bit easy while testing applications in different modes.

Disclaimer : I work for ebay Inc. The information in this post is compilation from my experiences in software industry and has no relation or recommendation from ebay Inc as such. ebay Inc will not be responsible for any information in this post. All the information in this post is only for educational purposes.