Stateful Mock Services: The Next Level of Service Simulation

When we hear the term mocks or simulated services, what often comes to mind are pre-configured transactions consisting of request/response and associated criteria to match for transactions.

Solutions like BlazeMeter Mock Services take traditional mocks to the next level by offering mechanisms to make them dynamic by integrating test data using data-driven services, or using parameter options and helper functions to make the response more realistic and dynamic.  

However, some use cases require state maintenance, or remembering the updates to the data, and this is an area where there are gaps with many existing mock service solutions. This type of scenario is where stateful mock services can be useful. 

This blog will take a closer look at stateful mock services and how this latest BlazeMeter capability makes the already-innovative capabilities associated with mock services even more cutting-edge. 

What Are Mock Services?

Mock services emulate the real behavior of a service including response times, response data etc. This makes them an ideal replacement for real services in scenarios where there are constraints with their availability, data, or usage.  

What Are Stateful Mock Services?

Stateful mock services are mock services that replicate a variety of state changes.  

This type of mock services can manifest itself in a few different ways:  

1. Maintaining updates to certain fields of data. For example, an update to the address field will change the address of the customer.  
2. Incremental changes to certain fields, such as how a deposit of funds into an account will change the state of the account balance.   
3. Maintaining an object state. In some complex scenarios, this may refer to maintaining a hash map of key-value data instead of storing individual values. 

Let us consider the scenario of updating demographics for a banking customer. If there is an address change for a customer in the bank using the address update service or API, the updated address will appear the next time we search for customer details.  

Yet address changes are not a typical use case for teams to use mock services, as mock services do not cause an actual update to the backend. This lack of updating the backend is helpful in scenarios like performance testing, which typically involves a huge data set up to deal with data burnout.  

Once an update is made, the script cannot reuse that data element and needs to move on to the next. However, since there are no true updates with a mock service, the data element can be used several times. 

There are certain scenarios where stateful mock services are useful: 

1. Functional Testing scenarios. 
2. Training environments. 
3. Sandbox environments. 

Let us take a closer look at each use case. 

Stateful Mock Services & Functional Testing 

While doing Functional Testing, it is sometimes important to determine how the application under test behaves once the updates are made. For instance, if we update the balance amount or if we enable a certain flag on the customer account which may enable a different flow in the application etc.  

If the state is not maintained, it may not be a true end-to-end flow validation.  

Stateful Mock Services in Training Environments 

In training environments, the trainees will want a real-world experience of how the application would behave. If they do not see the updates reflected in the application, it can be confusing and may not provide them with the real-world experience they can rely on as part of their training.  

Stateful mock services can be helpful in addressing this scenario by providing a more realistic portrayal of application behavior. 

Stateful Mock Services in Sandbox Environments  

In sandbox environments, instead of setting the end-to-end systems, using stateful mock services provides a cost-effective way for developers and other team members involved in testing to do their early-stage testing without any disruptions. This is also helpful as a third-party service provider to provide environments to the number of consumers as a sandbox environment in a quick, cost-effective manner.  

We are excited to announce that BlazeMeter now supports stateful mock services. With this new feature, BlazeMeter enables users to perform mock service state updates and maintain global counters as part of test runs. These state updates persist between stops and restarts of the mock services.  

This feature is available under the processing actions of a mock service along with other advanced features such as HTTP Calls (for making external calls synchronously) and Webhooks (for making external calls asynchronously).  

The state updates are made to data parameters in the service data and to global data parameters. Global data parameters are available to the whole service and are listed in the global scope section of the service data panel.  

The different operations that can be performed as part of state updates are as follows. These operations happen when the transaction match happens.  

• Store Object – Adds a row of values to the data entity.

• Update Object – Updates a specific value or values in an existing row in a data entity.

• Delete Object – Deletes a specific column value in an existing row in a data entity.

• Update Value – Updates a global value.

• Incremental Value – Increases or decreases a global value incrementally (typically counters).

A combination of test data and stateful updates takes Blazemeter mock services to the next level by offering stateful mock services capability which is a unique offering and can deliver a lot of value for its users.

Experience this latest BlazeMeter feature today with our free trial. 

Start Testing Now