Build your tests more robust & flexible with Output Relay

Overview

This guide focuses on practical implementation and best practices for using Output Relay in your test pipelines.

Typical Use Cases for Output Relay

A typical use case involves testing multiple API request dependencies. For example:

• Case A: Retrieve a system access token for a user.
• Case B: Use the token obtained in Case A to call the "Get User List" service and retrieve a user ID from the list.
• Case C: Use the token from Case A and the user ID from Case B to call the "User Detail Service" and obtain location information for the user.

In this scenario, Case B depends on the output of Case A, and Case C depends on the outputs of both Case A and Case B. Output Relay helps maintain the independence of each test case while allowing these dependencies to be implemented, avoiding the need for complex and lengthy code logic.

Key Concepts

For a complete explanation of Output Relay concepts including Output Case, Input Case, Relay Variables, and data flow diagrams, see Understanding Output Relay.

How to Use Output Relay

Writing Output Case and Input Case

To use Output Relay, you must first define both the Output Case and Input Case. For more details on how to write Output Case and Input Case, please refer to .

Configuring Test Pipelines with Output Case and Input Case

After writing the Output Case and Input Case, the next step is to correctly arrange them within the same test pipeline. For detailed steps on how to configure a pipeline using Output Relay, please refer to <Test pipeline writing guideline & samples>.

Execution Logic vs. Standard Pipelines

A test pipeline with Output Relay differs from a standard pipeline because explicit data dependencies exist between test cases. In rule/v1.3, sibling cases without explicit dependencies can still be scheduled in parallel. However, once a case depends on relay output, the platform requires the test script that provides relay data to finish cleanly before the test script that consumes relay data starts. In other words, Output Relay does not force every pipeline into a fully sequential model; it preserves correct data dependency under parallel-capable execution.

Common Misconfigurations and System Responses

Some common misconfiguration examples are as follows:

• Misconfiguration Example 1: Case B is set to execute only if Case A fails. The system will reject this configuration.
• Misconfiguration Example 2: Case B depends on the output of Case A, but Case A has not declared any output. In this case, the system will not reject the configuration, but in the pipeline details page, the user will not see any test cases marked with the Relay Output Case flag. This will remind the user to review the dependency settings to ensure they meet expectations.

Common Issues and Best Practices

Best Use Cases for Output Relay

The Output Relay feature is best suited for the following scenarios:

• Multi-step functional testing, where each step depends on the output of the previous step.
• API call chains, where relay data reduces redundancy.
• Integration testing, where credentials or other dynamic data from previous steps need to be reused.

Common Errors and Troubleshooting Methods

Below are some common errors and suggestions for troubleshooting:

• Undeclared Output Variables: If the Output Case does not declare its output variables correctly, the system will use the initial value of the Input Case. If the test results do not meet expectations, check the dependency configuration and ensure that the output and input variables are correctly declared.
• Illogical Test Configuration: If an Input Case is set to execute when the Output Case fails, the system will reject this configuration. This situation may arise if the user incorrectly sets the execution order. Adjust the pipeline logic to ensure the sequence of test case execution aligns with the intended dependencies.

Writing Efficient Relay-Dependent Test Cases

To fully utilize the Output Relay feature, users should follow these best practices:

• Clearly differentiate the execution logic in the pipeline (e.g., whenpassed, whenfailed) from dependencies introduced by Output Relay (ref) to avoid confusion in pipeline configurations.
• In rule/v1.3, if a downstream case depends on relay output, avoid placing it in a sibling relationship that could become ready at the same time as the test script that provides its relay data.
• Maintain the atomicity of test cases, ensuring that each test case performs only a single, independent function.
• Clearly declare output and input variables to ensure that dependency relationships are transparent.
• Avoid creating overly complex dependency chains; keep test cases simple and maintainable.