Book a demo

Test Cases

Discover how to build effective test scenarios for different integration 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.

1

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 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 result

The expected result defines what the output of the flow should be after execution. It’s used to compare the actual result with the expected one.

Provide the following:

  • Operator: The comparison operator to be used. Currently the only available option is Equals.

  • JSONPath: The JSONPath expression pointing to the result field.

  • Value: The expected value, in JSON format.

2

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.

3

Save the test

Once all required information has been provided, click Save.

The test case must contain at least the name and the expected result to be saved.

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.

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.

  1. To view the execution details on the Execution panel, click Open execution. More information can be found on the Results tab.

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 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:

[    
 {
   "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:

{
 "customer": {
   "name": "Customer Default",
   "ssn": "123-45-6789"
 }
}

  • Mock Response: (Leave empty for this example)

  • Expected result:

    • JSONPath: $.customer

    • Value:

{
   "name": "Customer Default",
   "ssn": "123-45-6789",
   "birthDate": "01/01/1970"
}

Result validation

After running the test case, the output is as follows:

{
  "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: Retrieves product data.

  2. Transformer (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:

[
  {
    "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:

{
  "product": {
    "id": "12345",
    "name": "Smartphone X1",
    "brand": "TechBrand",
    "price": 699.99,
    "currency": "USD",
    "stock": 25
  }
}

  • Expected result:

    • JSONPath: $.details

    • Value:

{
    "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:

{
  "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.

PreviousDesign and Inspect ModeNextLinter: Canvas building validation

Last updated

Was this helpful?