CONTINUOUS TESTINGTEST ENVIRONMENTSDynamic Mock Services: Your Team’s New Secret Weapon

Completing all necessary in-sprint testing is challenging and can be made more difficult when testing teams do not have access to the environment they need. Luckily BlazeMeter has introduced Mock Services into its testing platform to ease environment challenges.
Avatar Murali KrishnaMarch 18, 20208 min

Blog post written by Murali Krishna and Beverly Mindle

Enterprises are putting more and more pressure on development teams to achieve agility; this pressure stems from wanting to produce new features quickly, respond to market change, beat the competition, and meet market demand. In order to reach and sustain true agility, it’s imperative to have strong continuous testing practices. Without a working continuous testing set-up, an increase in new features being added to an application will also result in an increase in new defects which will degrade customer experience and slow down the output of additional features.


Completing all necessary in-sprint testing is challenging and can be made more difficult when testing teams do not have access to the environment they need. In fact, 81% of large to mid-sized enterprises reported that agile teams spend up to one-third of their time with testing environments.  Luckily BlazeMeter has introduced Mock Services into its testing platform to ease environment challenges.

What Do We Mean By Mock Services?


Mock Services helps by virtualizing (simulating) the behavior of the downstream systems. This allows agile teams to isolate their system under test and call upon Mock Services to simulate processes that might be unavailable, still under development, difficult to reproduce (negative scenarios/Disaster Recovery testing), or part of a third party service that is outside your control.

Fundamentally, Mock Services consists of transactions which are just request/ response pairs for the downstream service/system that you need to virtualize.  Let’s discuss how an agile team might set-up Mock Services and fine tune them to be more dynamic and responsive to their needs. This type of testing is known as chaos testing.

What is Chaos Testing?


Chaos testing helps ensure that a system can withstand unexpected disruptions in a function by throwing “what if” scenarios at it. This allows you to test your application early and often for a new feature that has not yet been developed or released, for example. The following scenarios show how mock services can be configured dynamically for different development requests that are certain to come your way.

Example 1: Creating a Request/Response Pair


A Product Owner brings to sprint planning a new feature that will add value to the business and its customers.  The agile team decides to develop this new feature which consists of a requirement to enhance a sales pipeline tool and rate a prospect as Cold, Warm, or Hot lead, based on past engagement.  

A typical development process would go like this:

  • An API developer would design how the API works
  • A UI developer would create the new feature
  • A QA engineer would test the new feature

Once the feature is complete the Product Owner reviews and signs off on it.  However, to truly shift left and develop and test continuously, we cannot have one member of the team wait for someone downstream to finish their work.  Instead, once the contract of how the API should work is defined, the API developer can create a Mock Service which will provide an endpoint response for his colleagues to use before even writing a single line of code. The following screens show how this is accomplished in BlazeMeter.

Request Configuration

Response Configuration

Notice that a regular expression has been used in the Request Matcher, so that any GET call to access lead information will provide the configured response.  Therefore, the bottleneck of waiting for actual code has been removed. Now the UI developer can use this API to work on the display part of this functionality, the QA engineer can define functional and performance tests for this new API, and API developer can continue to work on the actual implementation.  This contract of how the Service should respond act as single source of truth so that multiple members of the agile team can work parallelly to complete this feature faster.

Example 2: Modifying the Request/Response Pair

As is often the case in agile development, once the team has completed the initial requirement, the Product Owner will ask the team to enhance the current feature. In this example, the enhancement requests the capability for users to filter the page based on lead status.

As the API developer begins to analyze the requirements, he realizes that there are a couple of scenarios to account for:

Scenario 1: If no status is provided (default API) in the URL, then the service should return the default response in Example 1

Scenario 2: If the URL has a query parameter with status, then all the leads in the response should have the matching status

The API developer can utilize the existing Mock Service transaction by leveraging the power of making the responses dynamic. He can quickly update the mock endpoint by replacing the hardcoded “status”=”WARM” with a dynamic expression which uses “not” as shown below

 “status”:${#not request.query.status} “WARM” ${else} “${request.query.status}” ${/not}

This syntax checks if the query parameter “status” is present. If not present, then the hardcoded value (“WARM” in this case is returned) or else the status value of query parameter is returned


Would return all the leads with status COLD


Would return all the leads with status NEW. The following screen shows an example of this response. 

Similar to the first example, this small change to the existing Mock Service can support QA and UI Engineers to continue working on their work in parallel as the API itself continues to be developed. 

Example 3: Configuring Random Responses

The agile team completes the work for the API and shares it more broadly.  An architect reviews the API and recommends adding an ETag response header and support to XML response based on the requested media type.  The API Developer can fix the transaction in the Mock Service by using “randomValue” and “eq” conditional helpers to ensure the data is returned in the correct format.

The following expression could be used for ETag and the Content-type in the response header configuration of the transaction.

${randomValue length=24 type=’ALPHANUMERIC’}


We could use “assign” and “eq” helpers to generate json or xml response based on “Accept” request header.

assign – would assign the value of “Accept” header to a variable. In our case it’s “mediaType”.

eq – Checks if the value of “mediaType” is equal to “application/json” or “application/xml” and returns the result based on that.

Here is the final response configuration

${#assign “mediaType”}${request.headers.Accept}${/assign}

${#eq mediaType ‘application/json’}





      “name”:”Mario Speedwagon”,

      “status”:${#not request.query.status} “HOT” ${else} “${request.query.status}” ${/not}





${#eq mediaType ‘application/xml’}




      <name>Mario Speedwagon</name>

      <status${#not request.query.status} HOT ${else} ${request.query.status} ${/not}</status>




Now we can see that different, curl commands to fetch different responses from the same transaction.


Scenario 1: The result would return leads in XML format


curl –request GET \

  –url \

  –header ‘accept: application/xml’


Scenario 2: The result would return leads in JSON format with status “NEW”


curl –request GET \

  –url ‘’ \

  –header ‘accept: application/json’


Adopting mock endpoints early in the development stage helps bring clarity to the entire team on how the final API is going to look. With dynamical responses and through chaos testing this endpoint can be made smarter and can generate different responses based on the incoming requests.


As you can see, you have a lot of flexibility in controlling how Mock Services should respond.  Through regular expressions and dynamic response options you can control what scenarios should match a given transaction and how the transaction should respond with the appropriate formatted data.  Additionally, if you want to have multiple match scenarios there is also a priority field when adding transactions to a Mock Service where you can rate which transaction should match first (i.e. have the specific transaction for a given user match first and have the more generic call match second).  To make your transactions more dynamic, please check out our documentation. To learn more about BlazeMeter Mock Services please visit us at


Murali Krishna