API Virtualization – ACCELQ

ACCELQ's API virtualization allows you to set up Service simulation by responding to API calls with mock responses. Example use cases below:

To test your application UI when some of the backend API services are still under development
Application-under-test needs to communicate with an external API that is not accessible during the test execution
When you deliberately want to prevent your testing from hitting the API services for cost or other resource considerations.

Virtualization is achieved by passing the API calls through a server that is equipped with a ruleset for intercepting requests and mocking responses. If there is a matching rule for the given API call, a mock response is returned by the Virtualization server. If not, the API call is passed through in the original route for the normal response.

ACCELQ achieves API virtualization through a set of simple commands that you can use in your Action logic.

Define virtualization rule

This command defines a service virtualization Rule which involves identifying the API call that should be intercepted and the mock response that should be returned. Every Rule should be provided with the following identifiers to allow referencing in the subsequent commands:

A reference name to identify and reference the rule in subsequent commands. Make sure this is functionally meaningful.
A group name for related rules (may be for all rules belonging to a particular service or all the rules for variations of an end-point etc.). A default group name is provided by the system if you skip this.
Request matching criteria – URL, Endpoint, Method Type, Contents of Body, Headers, Query Params
Response Template – Response status, body, headers that should be returned as part of the mock response

Apply post processor to virtualization rule

This command is used to apply a post processor to a virtualization rule. A post-processor is a piece of custom logic that allows you to manipulate the mock response generated by a virtualization rule before it is returned to the consumer.

You can apply a post processor to either a single virtualization rule, all the rules belonging to a group, or all the defined virtualization rules in one shot, depending on the selection criteria you specify.

To use this command, you need to specify the selection criteria, as well as the reference names of the virtualization rule or group you want to apply to the post-processor. You also need to provide the names of the post-processor Actions as a comma-separated list. These Actions should belong to a Context named AQ$V12NPostProcessor, and they will have access to both the request and the mock response generated by the virtualization rule.

It is important to note that you must run this command before you enable the virtualization rule, as the post-processor must be added before the rule takes effect at runtime.

This command has the following parameters:

rule selection criteria: This parameter specifies the criteria you are using to select the virtualization rules you want to apply the post processor to. You can choose from three options: "all virtualization rules", "virtualization rule", or "virtualization rule group".
rule ref name: This parameter is used to specify the reference name of a specific virtualization rule. It is only required if you have chosen the "virtualization rule" as the selection criteria.
group ref name: This parameter is used to specify the reference name of a virtualization rule group. It is required if you have chosen the "virtualization rule" or "virtualization rule group" as the selection criteria.
post processor Action names: This parameter is a comma-separated list of the names (literal only) of the post-processor Actions you want to apply to the virtualization rule. These Actions should belong to a Context named AQ$V12NPostProcessor and will have access to both the request and the mock response generated by the virtualization rule.

Refer here to create a Post-process Action to modify the response of the invoked request.

Enable virtualization rules

This command enables virtualization for the API calls covered by the Rules already defined with the previous command. You have an option to enable virtualization by

Reference name, when you want to pick one or more Rules explicitly
Group name, which enables all the related Rules belonging to a group
All services, which enables virtualization for all the API calls which are covered by the Rules

You may include multiple statements with this command to enable a series of virtualization Rules.

Disable virtualization rules

This command disables virtualization for the specified list of Rules. Maintaining symmetry with the "Enable" command, this command also supports three options below:

Reference name, when you want to disable one or more Rules explicitly
Group name, which disables all the related Rules belonging to a group
All services, which disables virtualization all together

Note: Once a simulation Rule is defined and enabled, it is active for the entire test run (unless you disable it explicitly). When you are running in parallel thread mode, each thread is expected to define its own set of Rules and enable it.

Delete Virtualization Rules

Clears/removes an already defined virtualization rule. This is different from enabling/disabling Rules, as the Rule is completely removed from the scope. You can either remove Rules by reference name, group name, or all the Rules in one go.

Set virtualization scope

Virtualization involves sending the API calls through a virtualization proxy to determine if there is a matching Rule. On a high level, you can choose to decide which of the API calls will be passed through this virtualization proxy:

ACCELQ API calls only; With this setting, only the API test cases defined in ACCELQ are evaluated for virtualization
Application API calls only: This setting enables only the API calls made by the test application (Web or Mobile) to pass through the proxy for evaluation. These are the API calls that your test application makes when you are running tests on the front-end.
All API calls: All the API calls during the test run are passed through the virtualization proxy.

If you do not use this command in your Action logic, by default virtualization is enabled for all API calls.

Note: To ensure web/mobile application API calls pass through the virtualization setup, the simulations must be enabled before the browser or mobile device is invoked in your test logic.

Note: Virtualizations are not supported when you are running your tests on third-party device providers such as Browser Stack or Sauce Labs.

Example for virtualization

The following Scenario uses virtualization to return a mock response for the QBank API to get credit card offers listing.

The logic for the virtualization Action (Step 1 above) involves logic as shown here:

Load the JSON to use as the mock response.
Define virtualization rule for credit card listing API call, using the mock response
Enable virtualization

Behind the scenes

When you work with service virtualization, ACCELQ sets up a virtualization server on the Agent machine which intercepts API calls based on the defined scope. If there is a matching Rule, this server responds with the pre-defined response from the Rule definition.

By default, ACCELQ picks the ports dynamically to enable this service. But if you have a requirement to use specific port numbers only, you can provide this information in the agent.properties file.

Following properties are relevant in the agent.properties file (optional).

virtualization_ports_range=    # provide a range of numbers to use for virtualization

If this property is left blank, system will pick port numbers dynamically. When providing the port numbers, make sure the range is big enough to accommodate concurrent threads/jobs you anticipate to run. Number of ports required may be up to twice the number of anticipated concurrent threads/jobs.

Note: If you had set HTTP/HTTPS proxy properties in the agent.properties file for other connectivity requirements, it will continue to be honored, except for the API calls matching the virtualization Rules.

Data Virtualization with ACCELQ's Parametrization

A powerful advantage of ACCELQ’s Virtualization feature lies in its deep support for parametrization within Action logic. This allows mock responses to be dynamically crafted based on incoming request data, environment variables, test context, or even external data sources. This capability transforms traditional static mocks into intelligent, data-driven virtual services, enabling comprehensive testing at scale.

The mock response passed as part of defining a virtualization rule is a variable that can be logically constructed.

What is Data Virtualization?

Data Virtualization in the context of service mocking means the ability to simulate realistic and dynamic responses using external or variable data inputs—rather than returning static, hardcoded payloads. This enables virtual services to behave more like real systems, making them highly valuable for testing modern, data-driven applications.

Without data virtualization, a static mock might always respond with:

If you want to return a different user, you would need to create a separate mock rule manually.

With data virtualization in ACCELQ, you can define a mock such that when a request like GET /users/101 is received, the Action logic fetches or computes data dynamically (e.g., from a CSV file, database, or test context). The response might then look like:

This is done by parameterizing the response fields using ACCELQ expressions or by retrieving data dynamically during test execution.

Why This Matters

Scalability: Test hundreds or thousands of scenarios without manually defining each one.
Realism: Your virtual services reflect real-world behavior, improving confidence in test outcomes.
Flexibility: Adapt mock responses to various test conditions, user roles, or runtime inputs.
Efficiency: Reduces maintenance overhead by using a single, generalized rule to simulate multiple conditions.

Implementation in ACCELQ

When defining a Virtualization Rule, the Request Match Criteria can capture dynamic aspects (e.g., path parameters, query strings, headers), which can then be passed into your Action logic. Inside the Action, you can:

Use input parameters to guide logic.
Fetch test data from various data sources or external files.
Construct dynamic responses based on rule logic.