An Introduction to API Virtualization (Service Mocking) in ACCELQ

API Virtualization, also known as Service Mocking or Simulation, is a powerful technique used to create a "dummy" or "fake" version of a REST API. This allows teams to test applications in a controlled environment, independent of the real backend services.

Key benefits of using API Virtualization:

• Isolate and Test: Test your application even when a dependent API is unavailable, unstable, or still under development.
• Simulate Any Scenario: Easily create mock responses to test edge cases, such as server errors (500, 403), slow response times, or specific data payloads that are difficult to reproduce with a live service.
• Parallel Development: Enable front-end and back-end teams to work in parallel, with the front-end team testing against a stable, virtualized API.
• Cost Reduction: Avoid hitting rate-limited or paid third-party APIs during repeated test runs.

The workflow in ACCELQ is straightforward: you Define rules to intercept API calls, Enable them to start the simulation, and optionally use Post-Processors for dynamic responses.

The Core Virtualization Workflow

Managing virtualization involves defining rules and controlling their lifecycle.

1. Defining a Virtualization Rule

This is the foundational step where you map a request pattern to a mock response.

• Command: Define Virtualization rule
• Purpose: This command creates a rule that listens for a specific API request and returns a pre-configured response when the criteria are met.
• Key Parameters:
  • Identification:
    • ref name: A unique name for the rule so you can enable, disable, or delete it individually.
    • group: An optional name to categorize related rules together.
  • Request Criteria: This is how ACCELQ matches an outgoing API call. You can set criteria for:
    • Base URL, method type, and endpoint (with matching logic like "equals to", "contains", "with regex").
    • Request body, headers, and query params.
  • Mock Response: This is the fake response ACCELQ will serve.
    • Response status code, response body, response headers.

2. Activating and Deactivating Rules

A defined rule is dormant until you explicitly activate it.

• Enable virtualization rules: Activates one or more defined rules. You can enable a single rule by its reference name, all rules in a group, or all defined rules at once.
• Disable virtualization rules: Deactivates rules, making them inactive without deleting their definitions. This is useful for temporarily turning off a simulation.
• Delete virtualization rules: Permanently removes one or more rule definitions.

Advanced Capabilities

For more complex scenarios, ACCELQ provides advanced control over the scope and dynamism of your mock services.

Dynamic Responses with Post-Processing

Sometimes a static mock response is not enough. You may need to generate a response dynamically based on the content of the incoming request (e.g., echoing a correlation ID from the request header into the response header).

This is achieved using a Post-Processor Action.

• Command: Apply post processor to virtualization rule
• How it works: This command links a virtualization rule to a special ACCELQ Action. This Action must be created within a Context named AQ$V12NPostProcessor. The post-processor must be applied before the rule is enabled.
• Inside the Post-Processor Action, you can use a special set of commands to manipulate the response:
  • Get request info of current virtualization request: Reads data from the original incoming request that was intercepted (e.g., its payload, headers, or query parameters).
  • Get response info of current virtualization request: Reads data from the mock response that is about to be sent.
  • Update virtualization response body (post process): Overwrites the mock response body.
  • Update virtualization response status code (post process): Overwrites the status code.
  • Update virtualization response headers (post process): Adds, updates, or removes headers from the mock response.

Controlling Virtualization Scope

You can control which API calls are intercepted by the simulation engine.

• Command: Set virtualization scope
• Purpose: To define whether the simulation applies to ACCELQ's own API test steps, API calls made by your application under test (e.g., from a web browser), or both.
• Scopes:
  • ACCELQ API calls only
  • Application API calls only
  • All API calls
• Important Note: When setting the scope to include application API calls, this step must be executed before the browser is invoked.

Accessing Proxy Information

• Command: Get virtualization proxy port
• Purpose: ACCELQ's virtualization engine runs on a local proxy. This command returns the port number for that proxy instance, which can be useful for advanced debugging or configuring external tools.