# Test Cases
A **Test Case** is a configuration that includes a defined set of inputs, conditions, and expected outcomes used to verify that a specific integration pipeline is working as intended. Test cases are especially useful for ensuring the quality of your integrations and documenting the expected behavior of your flows.
They allow you to:
* Simulate various input conditions.
* Mock connector responses.
* Automatically compare actual and expected results.
## **Creating the Test Case**
1. In the sidebar on Canvas, go to **Flow**.
2. Click **Create a new test case**.
{% stepper %}
{% step %}
### Define the conditions
When creating a test case, you must configure the elements that define the test scenario:
#### **Payload**
The payload represents the input data for your test. When adding a payload, provide the following:
* **JSON:** The input data in JSON format. You can also reuse [payloads previously saved in the Execution Panel](https://docs.digibee.com/documentation/developer-guide/development-cycle/build-overview/execution-panel#payload-column) of the pipeline by clicking **Load to edit**.
* **Name:** A name for the payload.
* **Description:** A short description explaining the context or purpose of the payload.
#### **Mock Response**
Mock responses let you simulate connector outputs, which is helpful when validating flows under different conditions. When adding a mock response, provide the following:
* **Connector:** The connector whose response you want to mock.
* **JSON:** The simulated response, in JSON format.
* **Name:** A name for the mock response.
* **Description:** A brief explanation of the scenario represented by this mock.
To simulate more connectors, click **Add more mocks**.
#### **Expected Results**
The expected result defines the output the flow should produce after execution. It is used to validate the execution by comparing the actual result with the expected one through configurable conditions and operators.
Start by providing the following information:
* **Name:** A unique identifier for the assertion.
* **Description:** A brief explanation of what is being validated.
After that, add one or more conditions. To add a condition, click **Add condition** and configure the following fields:
* **JSONPath:** The JSONPath expression that points to the result field to be evaluated.
* **Operator:** The comparison operator used to validate the result. The available options are:
* **Equals, Not Equals:** Checks whether the returned value is equal to or different from the expected value.
* **Greater Than, Greater Than Or Equal:** Checks whether the returned value is greater than or greater than or equal to the expected value.
* **Less Than, Less Than Or Equal:** Checks whether the returned value is less than or less than or equal to the expected value.
* **Is True, Is False:** Validates whether the returned value is a boolean set to `true` or `false`.
* **Is True, Not Null:** Validates whether the returned value is `null` or defined.
* **In, Not In:** Validates whether the returned value belongs to or does not belong to a defined set of values.
* **Is Empty, Is Not Empty:** Checks whether the returned value is empty or contains at least one value, element, or property.
* **Contains, Not Contains:** Checks whether the returned value includes or does not include the expected content.
* **Value:** The expected value to be compared. This can be a Simple Value or a JSON Object. Use the toggle in the field to switch between formats.
{% hint style="info" %}
Some operators perform state checks and don’t require a value, such as **Is True**, **Is False**, **Is Null**, **Not Null**, **Is Empty**, and **Is Not Empty**.
{% endhint %}
You can combine multiple conditions using the following logical operators:
* `AND`
* `OR`
{% endstep %}
{% step %}
### Document the test
Before saving the test case, make sure to provide the following information:
* **Name:** A unique name to identify the test case later.
* **Description:** A brief explanation of the test case. Use this field to document the purpose or specific scenario being tested.
* **Group:** A group to organize the test case. Click **Create your first group** to start grouping your test cases or select an existing group to assign your test case.
{% endstep %}
{% step %}
### **Save the test**
Once all required information has been provided, click **Save**.
{% hint style="info" %}
The test case must contain at least the name and the expected result to be saved.
{% endhint %}
The test case will then appear in the left sidebar under the **Flow** section. From there, you can click the three-dots icon to:
* **Edit:** Modify the test case settings.
* **Remove:** Delete the test case.
* **Duplicate:** Make a copy of the test case.
* **Single Run:** Execute the test case.
* **Open execution:** Only available after the test case is executed.
{% endstep %}
{% endstepper %}
## **Running the Test Case**
To execute the test case:
1. Ensure the flow is connected to a trigger. If the flow isn’t connected, the test case won’t run.
2. In the sidebar, locate the test case and click the three-dots icon.
3. Select **Single Run** to start the execution.
4. The test will run, and the platform will compare the actual output with the expected result:
* **If it passes:** A green success icon appears next to the test case name.
* **If it fails:** A red failure icon appears next to the test case name.
5. To view the execution details on the **Execution panel**, click **Open execution**. More information can be found on the **Results** tab. You can also expand the **Messages** section in the left-side panel to analyze the output of each individual connector.
## **Example: Add default birth date**
* **Use case:** You want to ensure that a default birth date is added when the input JSON is missing.
* **Objective:** Use the [**Transformer (JOLT) V2**](https://app.gitbook.com/s/EKM2LD3uNAckQgy1OUyZ/connectors/tools/jolt-v2) to add a default `"birthDate": "01/01/1970"` field when it’s not present in the input.
### **Pipeline overview**
This pipeline uses a single connector:
* **Transformer (JOLT) V2:** Adds a default birth date if it’s missing from the input payload.
We’ll test this transformation using a test case with a sample input that lacks the `birthDate` field.
### **Step 1: Configure the Transformer JOLT (V2)**
We’ll use the `default` operation to add a field when it doesn't already exist.
**JOLT specification:**
```json
[
{
"operation": "default",
"spec": {
"customer": {
"birthDate": "01/01/1970"
}
}
}
]
```
This spec checks if `birthDate` exists under `customer`. If not, it adds it with the default value `”01/01/1970”`.
### **Step 2: Create the Test Case**
We'll simulate a payload that contains only the name and SSN, and verify that the Transformer (JOLT) V2 connector adds the default birth date.
* **Payload:**
```json
{
"customer": {
"name": "Customer Default",
"ssn": "123-45-6789"
}
}
```
* **Mock Response:** *(Leave empty for this example)*
* **Expected result:**
* **JSONPath:** `$.customer`
* **Value:**
```json
{
"name": "Customer Default",
"ssn": "123-45-6789",
"birthDate": "01/01/1970"
}
```
### **Result validation**
After running the test case, the output is as follows:
```json
{
"customer": {
"name": "Customer Default",
"ssn": "123-45-6789",
"birthDate": "01/01/1970"
}
}
```
This confirms that the test passed:
* The **Transformer (JOLT) V2** applied the `default` operation as expected.
* Since the original input didn’t include a `birthDate`, the field was added with the default value `”01/01/1970”`.
## **Example: Organize product catalog**
* **Use case:** You want to restructure product data returned from a database into a new format.
* **Objective:** Group product details under a `details` object and rename fields for better organization.
### **Pipeline overview**
This pipeline uses the following connectors:
1. [**DB V2**](https://app.gitbook.com/s/EKM2LD3uNAckQgy1OUyZ/connectors/structured-data/db-v2): Retrieves product data.
2. [**Transformer (JOLT) V2**](https://app.gitbook.com/s/EKM2LD3uNAckQgy1OUyZ/connectors/tools/jolt-v2): Reorganizes and renames the fields using the `shift` operation.
As we don’t have access to the actual database, we’ll simulate it using a test case with a mocked DB response.
### **Step 1: Configure the Transformer JOLT (V2)**
We’ll use a JOLT `shift` operation to map and reorganize the fields.
**JOLT specification:**
```json
[
{
"operation": "shift",
"spec": {
"product": {
"id": "productId",
"name": "details.name",
"brand": "details.brand",
"price": "details.pricing.amount",
"currency": "details.pricing.currency",
"stock": "details.availability"
}
}
}
]
```
This spec renames `id` to `productId` and nests other fields under a `details` object.
### **Step 2: Create the Test Case**
We'll simulate the database response and validate the transformation.
* **Payload:** *(Leave empty for this example)*
* **Mock Response:**
* **Connector:** DB V2
* **JSON Payload:**
```json
{
"product": {
"id": "12345",
"name": "Smartphone X1",
"brand": "TechBrand",
"price": 699.99,
"currency": "USD",
"stock": 25
}
}
```
* **Expected result:**
* **JSONPath:** `$.details`
* **Value:**
```json
{
"name": "Smartphone X1",
"brand": "TechBrand",
"pricing": {
"amount": 699.99,
"currency": "USD"
},
"availability": 25
}
```
### **Result validation**
After running the test case, the output is as follows:
```json
{
"productId": "12345",
"details": {
"name": "Smartphone X1",
"brand": "TechBrand",
"pricing": {
"amount": 699.99,
"currency": "USD"
},
"availability": 25
}
}
```
This confirms that the test passed:
* The **Transformer (JOLT) V2** applied the specification correctly to restructure the input data.
* Fields were renamed and nested under the `details` object as intended.
* The `productId` field remained at the top level, while other attributes were grouped logically under `details`.
