> For the complete documentation index, see [llms.txt](https://docs.acecloud.ai/knowledge-base/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.acecloud.ai/knowledge-base/functions/how-to-test-a-function.md).

# How to Test a function?

After creating and developing a function, you can test it from the **Test** tab in AceCloud Functions. The test interface lets you send HTTP requests to the function and view the response without using an external API client.

You can configure the request method, path, query parameters, headers, and request body, and then review the response status, latency, headers, and body.

### **Before you begin**

Make sure that:

* You have created a function.
* The function contains valid source code.
* You have saved the latest changes as a draft.
* The function is available in the **Editor** tab.

### **Open the Test interface**

1. Go to **Functions** from the AceCloud portal.
2. Select the function you want to test.
3. Select the **Editor** tab.
4. Select **Test**.
5. Click **Open Test Session**.

AceCloud creates a temporary runtime for the latest saved draft and opens the test interface.

Wait until the test session shows **Ready** before sending a request.

**Note:** The test session runs against the latest saved draft. If you make changes to the function, save the draft and refresh the test session before testing the updated code.

### **Send a Test Request**

The **Request** section allows you to configure the HTTP request sent to your function.

The request contains the following fields:

* HTTP method
* Request path
* Query parameters
* Headers
* Request body

#### **Select the HTTP method**

Open the HTTP method list and select the method required by your function.

The available methods are:

* GET
* POST
* PUT
* PATCH
* DELETE

For example, select **GET** when your function reads data without requiring a request body.

For functions that receive data, select the method expected by your handler, such as **POST** or **PUT**.

#### **Specify the request path**

Enter the path in the request path field.

For example:

/

You can also specify another path if your function handles different request paths.

#### **Add query parameters**

Use **Add parameter** under **Query Parameters** to add values to the request URL.

For example:

| **Parameter** | **Value** |
| ------------- | --------- |
| name          | John      |
| environment   | test      |

The function can read these values from the incoming event.

Example

query parameters: name = John and environment = test.

Use query parameters when your function expects information in the URL rather than in the request body.

#### **Add request headers**

Use **Add header** under **Headers** to add HTTP headers to the request.

For example:

| **Header**    | **Value**        |
| ------------- | ---------------- |
| Content-Type  | application/json |
| Authorization | Bearer           |

Headers are useful when your function expects content-type information, authorization data, signatures, or other request metadata.

The incoming request headers are available to the function through the event object.

### **Add a Request Body**

The **Body** section lets you send data with the request.

Select the required body type from the dropdown.

The available options are:

* **None**
* **JSON**
* **XML**
* **Multipart**

#### **None**

Select **None** when the function does not require a request body.

This is commonly used with GET requests.

#### **JSON**

Select **JSON** when the function expects a JSON payload.

For example:

{\
"name": "Alex",\
"message": "Hello from Ace Functions"\
}

Make sure the request uses:

Content-Type: application/json

Functions can read the request body from the event and parse the JSON payload according to the runtime and application code.

#### **XML**

Select **XML** when your function receives XML data.

For example:

Alex Hello

Use:

Content-Type: application/xml

when your function expects an XML request.

#### **Multipart**

Select **Multipart** when your function needs to receive multipart form data, such as uploaded files.

Multipart requests are useful for scenarios such as image or file uploads. The function can inspect the multipart request and process the uploaded data.

### **Send the Request**

After configuring the request:

1. Select the required HTTP method.
2. Enter the request path.
3. Add query parameters, if required.
4. Add headers, if required.
5. Select the request body type.
6. Enter the request body, if applicable.
7. Click **Send**.

The request is sent to the temporary test runtime.

### **View the Function Response**

The **Response** section displays the result returned by the function.

After the request completes, review:

* HTTP status
* Response latency
* Response headers
* Response body

Use these details to verify that the function is processing the request as expected.

For example, a function that returns a simple object can produce a 200 response with a JSON response body. A function can also explicitly return another status code, custom headers, or a non-JSON response when required.

#### **Check the HTTP status**

The HTTP status indicates whether the request was processed successfully.

For example:

200 OK

indicates a successful request.

If the function returns an error status such as 400, 401, 404, or 500, review the function code and logs to identify the cause.

#### **Check the response body**

The response body contains the data returned by your function.

For example:

{\
"message": "Hello, Alex"\
}

If your function returns a response with a statusCode, headers, and body, the test response reflects those values.

#### **Check response headers**

Response headers are displayed separately from the response body.

They are useful for verifying values such as:

Content-Type: application/json

or custom headers returned by your function.

#### **Check latency**

The response also shows the time taken to process the request.

Use latency to identify unusually slow executions while testing your function.

### **Test Different Request Scenarios**

You can use the same test session to verify different inputs.

For example, for a function that accepts JSON:

**Request**

Method: POST\
Path: /\
Content-Type: application/json

**Body**

{\
"name": "Alex"\
}

Send the request and verify that the function returns the expected response.

You can then change the input and send another request to test how the function handles different values.

For functions that use headers, query parameters, XML, or multipart data, configure the corresponding request fields before sending the request.

### **Test Event Selection**

The Test interface also provides an **Select an event** option.

Use this option when the function has testable events available in the current test session. Select the required event before sending the request.

If you are testing the function directly through HTTP, configure the request manually using the method, path, parameters, headers, and body fields.

### **Troubleshoot a Failed Test**

If the test does not return the expected result:

1. Verify that the test session shows **Ready**.
2. Check the HTTP method and request path.
3. Verify query parameters and request headers.
4. Check the selected body type.
5. Verify that the request body matches the format expected by the function.
6. Check the function's response status and body.
7. Open the **Logs** tab to review the function execution logs.
8. If the source code was changed, save the changes and start or refresh the test session with the latest draft.

For example, if a function expects a multipart upload but receives JSON, the function may reject the request based on the content type. Similarly, binary request data must be handled according to the function's event and encoding requirements.

### **What's next?**

After you have verified the function using the test session, you can deploy the tested source as a new function version.

You can then use:

* **Versions** to manage deployed versions.
* **Insights** to review function metrics.
* **Logs** to troubleshoot function executions.

## Additional Test Session Notes

Save the latest source changes as a draft before opening or refreshing the test session. The test session runs against the latest saved draft, not unsaved editor changes.

Wait until the session status displays Ready before sending requests. If you edit the source, select Save Draft and refresh the test session so the test uses the updated draft.

To stop a test session, open the three-dot menu in the Test interface and select Close Session. The menu may also show Delete event; this is a separate action and should not be used to close the session.

The request body limit is 10 MiB. Keep the request payload within this limit when testing.

For multipart requests containing binary files, the event represents binary content using Base64 encoding. The function code should decode that content before processing the original bytes, as required by the implementation.

### Review Logs

Open the Logs tab to investigate failed or unexpected requests. The visible filters include Request ID, Version, Show lines, and time range. Available time-range shortcuts shown in the interface are 15m, 30m, 1h, 1d, and 3d. Use Refresh to reload the results or Live tail to view incoming logs in real time. Log entries can include time, request ID, version, type, level, and message.

### Test Session Lifetime and Billing

A draft test session remains open until you close it; it does not automatically close while left open. Customers are charged for draft invocations (function invocations). Keeping the draft open is not itself an invocation. Close the session when you have finished testing.