Feature Availability: Release 5.0
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
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.
Clear 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.