Understanding Extensions

Functionize Extensions, also known as microservice endpoints, expand the possibilities of your test executions by making the Functionize platform fully programmable. Extensions expose our runtime object model, allowing you to manipulate and interact with nearly every aspect of test execution.

With Extensions, you can:

Adjust runtime input values
Work with uploaded and downloaded files
Process screenshots
Modify variables and expressions
Integrate with TDM (Test Data Management) systems
Access orchestration details
Add dependencies to orchestrations
Perform data deletion
Interact with external systems, such as APIs and databases

In short: Extensions unlock almost limitless flexibility, enabling you to programmatically modify tests in real time.

How Extensions Work

Extensions function as microservices that:

Receive runtime test step objects
Perform external processing (outside the test’s virtual machine)
Return responses that can update, override, or enhance the test execution flow

This means you can use Extensions to:

Alter test data mid-execution
Change outcomes dynamically
Build reusable logic and custom code

Extensions are similar in spirit to using Custom JS, but they go much further:

They are created once and can be reused across your entire organization
They can be mapped to test steps for pre-action or post-action execution
They can be mapped to test cases and orchestrations for post-action execution
They can be centrally managed, versioned, and scaled
You can import advanced libraries (e.g., for API requests, file handling, or complex data processing)
They can be mapped as a pre-hook or post-hook on a test step

Note: When Extensions are modified, deployment takes a few minutes before changes become active.

Deployment Models

Functionize Extensions can be deployed in two ways:

1. Internal Extensions

Hosted in the Functionize Cloud
Deployed as serverless cloud functions
Supported languages:
- Node.js 18
- Python 3.11
- Go 1.20
- Java 17
You may include external libraries to extend functionality

Limitations: Internal Extensions follow Google Cloud Functions limits (e.g., maximum payload size, execution time).

2. External Extensions

Hosted and managed by you in your own environment
Registered in the Functionize UI as endpoints
Can integrate with private services, on-prem APIs, or secure environment

Important: External Extensions must follow Functionize’s expected request/response format to ensure accurate communication.

Using Extensions

Extensions can be registered for:

Pre-Action Execution: Run before the step is executed to adjust inputs or data
Post-Action Execution: Run after the step is executed to process outputs, screenshots, or results

Additionally, Functionize provides a standalone Extension Action, which allows you to directly call an Extension as part of your test case. This makes Extensions ideal for integrating with external APIs or custom business logic during test execution.

Benefits of Extensions

Reusable Logic – Write once, reuse everywhere across your org
Flexibility – Adapt tests dynamically without rebuilding them
Programmability – Extend Functionize beyond out-of-the-box capabilities
Scalability – Use either Functionize-hosted (Internal) or self-hosted (External) endpoints, depending on your architecture
Variability – Use Functionize variables, such as project or environment variables, in the extension code
Integration – Connect test cases with external systems or datasets

Extensions: Custom Logic for Test Automation

Extensions are pieces of custom code (Node.js, Python, Go, Java) you write to execute personalized logic during a test run. They allow you to add advanced, step-specific functionality to your test cases.

Core Capabilities

Definition: Custom code functions that run on our platform.
Scope: Executed per action/step in a test case, not per entire test run.
Supported Languages: Node.js, Python, Go, and Java.

Execution Hooks

Extensions are executed at specific points relative to a test step:

Hook	Timing	Primary Purpose
Pre-hook	Runs before the action step.	Dynamically change the action's input data (e.g., set a unique username, modify a URL parameter).
Post-hook	Runs after the action step completes.	Evaluate results, capture generated data (e.g., a file path), or trigger subsequent logic (e.g., update a data source).

Key Use Cases

Extensions are used for high-demand, complex tasks:

Dynamic Data Input: Generating unique or calculated input values (e.g., random strings, timestamps).
File Comparison: Comparing contents of two files (CSV, JSON, etc.) and generating a structured report of differences.
TDM Integration: Programmatically updating or managing Test Data Management (TDM) sources.
API Workflow Simplification: Calling internal APIs (e.g., to generate an authentication token) to reduce explicit API steps.

Technical Essentials

Extensions receive an input object (data) and must return a formatted JSON object (response).

Input Data (`data` Object)

The extension code receives essential information about the current test step:

data.action: Details about the current action step (used for inspection and modification).
data.variables: All accessible variables (local and project scoped).
data.apiKeys: Authenticated user credentials (API Key/Secret) for internal calls.
data.action.fileURL: URL to retrieve file data attached to the step.

Output Structure

The returned JSON object is used to modify the test run's state:

To Modify the Current Action (Pre-Hook): Return an updates.actionAttributes block to override a specific attribute for the current step (e.g., changing the value of an input field).

Example: To change the input field's value to "New Data":


// Example: Modifying the 'value' attribute of the current action
const new_value = "My New Data";

return {
    updates: {
        actionAttributes: {
            // This key must match the attribute you intend to override
            "value": new_value 
        }
    }
};

To Store Data in Variables (Post-Hook): Return an updates.variables block to save results into a local or project variable.
Important: All variables only store string-ifiable data. Complex objects must be converted using JSON.stringify() before storage.
// Example: Storing a result object into a local variable
const results_object = { difference: 3, status: "Failed" };
return {
    updates: {
        variables: {
            "local": { // Targeting the local variable scope
                "fileComparisonResult": JSON.stringify(results_object)
            }
        }
    }
};

How to fetch the data from the local/project variable as input data into a Cloud extension

Example Variable: fze.local.alpha = 'testing';

In NodeJS Code:

exports.helloWorld = (req, res) => {
let input = req.body.variables.local.alpha || 'Oops, forgot to pass action.value to the extension';

In Java code:

public class Example implements HttpFunction {

@Override

public void service(HttpRequest request, HttpResponse response) throws IOException {

// Parse the JSON body from the request

Gson gson = new Gson();

JsonObject requestBody = gson.fromJson(

new InputStreamReader(request.getInputStream(), StandardCharsets.UTF_8),

JsonObject.class

);

// Fetch alpha from variables.local.alpha

String alpha = requestBody

.getAsJsonObject("variables")

.getAsJsonObject("local")

.get("alpha")

.getAsString();

response.getWriter().write(

"Value received successfully: " + alpha

);

}

Best Practices and Debugging

Debugging Technique

DO NOT use console.log()—it is not returned to the test results.
Debugging: To inspect data, pass the object you want to see (e.g., the entire data input) back to a local variable using JSON.stringify() in the post-hook response. This allows you to view the data in the Variables tab of the test results.

Search